Re: please test the new PyPI (now in beta)

[Sumana Harihareswara]

On Wednesday, March 28, 2018 at 1:17:20 PM UTC-4, William Ray Wing wrote:
> > On Mar 28, 2018, at 10:50 AM, sumana.hariharesw...@gmail.com wrote:
> > 
> > 
> 
> [byte]
> 
> > 
> > People who literally don't see the list of ways to filter on the left-hand 
> > side of https://pypi.org/search/
> 
> I do see the list of filters, but I only get it AFTER I’ve entered my first 
> search term.  I may be an outlier here, but I find that an unfortunate bit of 
> UI design.  I suppose it is deliberate in that the filters can then be used 
> to narrow search results, but if I know going in that I’m only interested in 
> a particular set of results, I’d like to be able to apply that filter to my 
> first search.
> 
> Thanks,
> Bill

Bill, thank you for the report. I have filed it at 
https://github.com/pypa/warehouse/issues/3462 and -- either there or here -- 
would appreciate knowing more about your experience so I can figure out how to 
reproduce it. What browser are you using? Do you have JavaScript turned off, or 
any relevant plugins installed (like Stylish)? What is your zoom level, if it's 
not 100%, and what is your window width? If you could email me a screenshot or 
add it to the GitHub issue, that would also help a lot.

best,
Sumana Harihareswara
-- 
https://mail.python.org/mailman/listinfo/python-list

Distributing Python virtual environments

[Malcolm Greene]

We're using virtual environments with Python 3.6. Since all our pip
installed modules are in our environment's local site-packages folder,
is the distribution of a virtual environment as simple as recursively
zipping the environment's root folder and distributing that archive to
another machine running the same OS and same version of Python? The
reason we would go this route vs downloading dependencies from a
requirements.txt file is that the target machines may be in a private
subnet with minimal access to the internet.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Distributing Python virtual environments

[Chris Angelico]

On Fri, Mar 30, 2018 at 1:06 AM, Malcolm Greene  wrote:
> We're using virtual environments with Python 3.6. Since all our pip
> installed modules are in our environment's local site-packages folder,
> is the distribution of a virtual environment as simple as recursively
> zipping the environment's root folder and distributing that archive to
> another machine running the same OS and same version of Python? The
> reason we would go this route vs downloading dependencies from a
> requirements.txt file is that the target machines may be in a private
> subnet with minimal access to the internet.

You'd have to also ensure that you have the same word size (32-bit,
64-bit, etc) and other criteria, and you'd have to ensure that the
same Python is available in the same location (since the venv's binary
is a symlink), but otherwise, I think you might be correct. As long as
you have the EXACT same setup, it will probably work. (Probably.) But
as an alternative, you may wish to consider replicating your PIP cache
(perhaps wiping it out first, to minimize its size); that should give
you the same ultimate effect of not requiring internet access, while
failing more gracefully if something goes wrong.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Distributing Python virtual environments

[Paul Moore]

On 29 March 2018 at 15:06, Malcolm Greene  wrote:
> We're using virtual environments with Python 3.6. Since all our pip
> installed modules are in our environment's local site-packages folder,
> is the distribution of a virtual environment as simple as recursively
> zipping the environment's root folder and distributing that archive to
> another machine running the same OS and same version of Python? The
> reason we would go this route vs downloading dependencies from a
> requirements.txt file is that the target machines may be in a private
> subnet with minimal access to the internet.

Typically that's not supported - wrapper scripts for example include
hardcoded path names that are specific to the original environment.
There's a --relocatable flag to the virtualenv command that (in
theory) tries to make the scripts use relative paths, but it's not
very reliable. Also, there are other potential risks in doing this -
as Chris said, you need to be very precise about architecture, etc.
Overall, I'd say this is a very risky approach.

A better approach would likely be to do "pip freeze" to generate a
requirements file (if you don't already have one), then "pip wheel -r
" to get a complete set of wheels for your
virtualenv. Then ship those wheels to the target machine (caveats
about exactly the same architecture still apply, as the wheels you
build may be architecture-specific), and build a new virtualenv and
install them with "pip install -r  --find-links
".

Paul
-- 
https://mail.python.org/mailman/listinfo/python-list

Converting list of tuple to list

[Ganesh Pal]

Hello Team,



I have a list of tuple say   [(1, 2, 1412734464L, 280), (2, 5, 1582956032L,
351), (3, 4, 969216L, 425)] .  I need to convert the above as
['1,2,1412734464:280',
'2,5,1582956032:351', '3,4,969216:425']



Here is my Solution , Any  suggestion or optimizations are welcome .



Solution 1:



>>> list_tuple = [(1, 2, 1412734464L, 280), (2, 5, 1582956032L, 351), (3,
4, 969216L, 425)]

>>> expected_list = []

>>> for elements in list_tuple:

... element = "%s,%s,%s:%s" % (elements)

... expected_list.append(element)

...

>>> expected_list

['1,2,1412734464:280', '2,5,1582956032:351', '3,4,969216:425']





Solution 2:

>>> list_tuple = [(1, 2, 1412734464L, 280), (2, 5, 1582956032L, 351), (3,
4, 969216L, 425)]

>>> expected_list = []

>>> for i in range(len(list_tuple)):

... element = list_tuple[i]

... ex_element = "%s,%s,%s:%s" % (element[0], element[1], element[2],
element[3])

... expected_list.append(ex_element)

...

>>> expected_list

['1,2,1412734464:280', '2,5,1582956032:351', '3,4,969216:425']

I know I should have not used len(range()) in  Solution 2, any more error
please let me know  , I am a Linux user on Python 2.7


Regards,
Ganesh
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: please test the new PyPI (now in beta)

[Sumana Harihareswara]

On Wednesday, March 28, 2018 at 9:36:56 AM UTC-4, Ethan Furman wrote:
> On 03/26/2018 03:16 PM, Sumana Harihareswara wrote:
> 
> > The new Python Package Index at https://pypi.org is now in beta.
> 
> The banner says:
> 
> --> This is a beta deployment of Warehouse. Changes made here affect the 
> production instance of PyPI (pypi.python.org).
> 
> Why is a beta instance affecting the production instance?
> 
> --
> ~Ethan~

The short answer is that pypi.org has to share data with pypi.python.org to 
provide people with a smooth migration path, and that test.pypi.org is 
available for users who want to try Warehouse without affecting production data.

And I recognize that the word "beta" implies different levels of reliability to 
different organizations; many people here remember GMail being "in beta" for 
five years at a pretty high service level, and some of us have used "beta" 
software that was about as robust as a wet tissue.

I've now done a few hours of research to nail down the history of this beta, 
and will put that in https://www.pypa.io/en/latest/history/ and other relevant 
documentation when I have it more sorted out. (I did some bug triage on 
Warehouse in 2016 but only started managing the project in December 2017.)

Warehouse has been up and available in some form as a preview since late 2013 
(see the original migration plan at 
https://mail.python.org/pipermail/distutils-sig/2013-July/022096.html ), it's 
had read access to the canonical PyPI database for at least three years (I'm 
still working out the exact dates), and since June 2016 we've advised people 
that it was a better experience to upload packages to the canonical PyPI 
database using Warehouse than via pypi.python.org (per 
https://mail.python.org/pipermail/distutils-sig/2016-June/029083.html and this 
change to the default `twine` upload URL https://github.com/pypa/twine/pull/177 
). In June/July 2017 we disabled uploading via the old site ( 
https://mail.python.org/pipermail/distutils-sig/2017-June/030766.html ). I 
believe Warehouse has been called "pre-production" for that whole time up until 
now, and now we're calling it "beta".

So I recognize that "beta affects production" is a phrase that might give you 
pause! But I hope this answers your question satisfactorily.

-Sumana Harihareswara
Warehouse project manager
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Converting list of tuple to list

[Rustom Mody]

On Thursday, March 29, 2018 at 8:42:39 PM UTC+5:30, Ganesh Pal wrote:
> Hello Team,
> 
> 
> 
> I have a list of tuple say   [(1, 2, 1412734464L, 280), (2, 5, 1582956032L,
> 351), (3, 4, 969216L, 425)] .  I need to convert the above as
> ['1,2,1412734464:280',
> '2,5,1582956032:351', '3,4,969216:425']
> 
> 
> 
> Here is my Solution , Any  suggestion or optimizations are welcome .
> 
> 
> 
> Solution 1:
> 
> 
> 
> >>> list_tuple = [(1, 2, 1412734464L, 280), (2, 5, 1582956032L, 351), (3,
> 4, 969216L, 425)]
> 
> >>> expected_list = []
> 
> >>> for elements in list_tuple:
> 
> ... element = "%s,%s,%s:%s" % (elements)
> 
> ... expected_list.append(element)
> 
> ...
> 
> >>> expected_list
> 
> ['1,2,1412734464:280', '2,5,1582956032:351', '3,4,969216:425']
> 

>>> ["%s,%s,%s:%s" % tuple for tuple in list_tuple]
['1,2,1412734464:280', '2,5,1582956032:351', '3,4,969216:425'] : list


> 
> 
> 
> 
> Solution 2:
> 
> >>> list_tuple = [(1, 2, 1412734464L, 280), (2, 5, 1582956032L, 351), (3,
> 4, 969216L, 425)]
> 
> >>> expected_list = []
> 
> >>> for i in range(len(list_tuple)):
> 
> ... element = list_tuple[i]
> 
> ... ex_element = "%s,%s,%s:%s" % (element[0], element[1], element[2],
> element[3])
> 
> ... expected_list.append(ex_element)
> 
> ...
> 
> >>> expected_list
> 
> ['1,2,1412734464:280', '2,5,1582956032:351', '3,4,969216:425']
> 
> I know I should have not used len(range()) in  Solution 2, any more error
> please let me know  , I am a Linux user on Python 2.7

Dont get the point…
Not just of the len
But also the fact that element is a tuple whose components you extract and
immediately put together back into the the same old tuple
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: please test the new PyPI (now in beta)

[Sumana Harihareswara]

On Wednesday, March 28, 2018 at 4:47:42 PM UTC-4, Terry Reedy wrote:
> On 3/28/2018 10:50 AM, sumana.hariharesw...@gmail.com wrote:
> 
> > People who literally don't see the list of ways to filter on the left-hand 
> > side of https://pypi.org/search/ : I ask you the usual list of 
> > troubleshooting questions. What OS and browser are you using, what plugins 
> > and particularly interesting preferences are you using, and so on. (When I 
> > turn off JavaScript in my browser, I see a list of clickable category 
> > headings like "By Programming Language" but clicking on them causes no 
> > response.) A screenshot in an issue at 
> > https://github.com/pypa/warehouse/issues would be helpful. (Reminder that 
> > participating in Warehouse development, including by filing an issue, 
> > requires abiding by the PyPA Code of Conduct 
> > https://www.pypa.io/en/latest/code-of-conduct/ .)
> 
> This is a window width issue.  Full screen (on my monitor), the 
> categories work fine, and clicking on them appears to work.  When I 
> narrow the browser window to about 1100 pixels, the category list 'to 
> the left' disappears and is replaced by an [Add filter] box.  When this 
> happens, "from the list of classifiers on the left." should be replaced 
> by "by clicking the button below."

Thank you so much for the detailed report, and the suggestion! Thanks also to 
another user who emailed me off-list to give me a detailed report of the 
problem in multiple browsers. I've updated 
https://github.com/pypa/warehouse/issues/3454#issuecomment-377207553 
accordingly.

>  >I recognize that many users want a more condensed view on many 
> pypi.org pages,
> 
> I consider reducing the search results from 60 to 10 per page to be 
> unacceptable and disrespectful of me as a user.
> 
> -- 
> Terry Jan Reedy

I appreciate you sharing your assessment. Thank you. I've filed 
https://github.com/pypa/warehouse/issues/3463 where I suggest we provide a 
widget on search results pages that allows the user to change the detault 
number of results in result pagination, e.g., "10 [default]/25/50/100/all". If 
that wouldn't address your concern, please let me know, here, via email, or on 
GitHub.

Sumana Harihareswara
Warehouse project manager
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: please test the new PyPI (now in beta)

[Sumana Harihareswara]

On Tuesday, March 27, 2018 at 6:28:12 PM UTC-4, Ian wrote:
> For me, the category filters alone are a killer feature over the old
> PyPI. I think it's also a plus to the Python community overall that
> PyPI not look to newcomers like something that was designed in the 90s
> and then abandoned.

Thank you! I am a fan of the category filters, too. And we've been hearing that 
sentiment (about the modern look) quite a bit.

> I agree with Steven about the unnecessary boxes around every single
> package, though. The presentation of the list of packages could be
> *much* denser while keeping the same readability, which would also
> make the page more usable by reducing the amount of scrolling needed.

I appreciate you sharing your experience. I'm linking to it in 
https://github.com/pypa/warehouse/issues/1988#issuecomment-377280770 . The more 
condensed view is something I'm asking volunteers for help with and I'm 
prioritizing it for post-launch work.

-Sumana Harihareswara
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: please test the new PyPI (now in beta)

[Ethan Furman]

On 03/29/2018 09:01 AM, Sumana Harihareswara wrote:


I appreciate you sharing your assessment. Thank you. I've filed [...snip 
details...]


Wow.  Thanks for all the confirmations of feedback received and issues created, Sumana!  I wish the big companies had 
user support this good.  :)


--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list

Re: Converting list of tuple to list

[Tim Chase]

On 2018-03-29 20:42, Ganesh Pal wrote:
> I have a list of tuple say   [(1, 2, 1412734464L, 280), (2, 5,
> 1582956032L, 351), (3, 4, 969216L, 425)] .  I need to convert the
> above as ['1,2,1412734464:280',
> '2,5,1582956032:351', '3,4,969216:425']
> 
> Here is my Solution , Any  suggestion or optimizations are welcome .
> 
> Solution 1:
> 
> >>> list_tuple = [(1, 2, 1412734464L, 280), (2, 5, 1582956032L,
> >>> 351), (3, 4, 969216L, 425)]
> >>> expected_list = []  
> >>> for elements in list_tuple:  
> ... element = "%s,%s,%s:%s" % (elements)
> ... expected_list.append(element)

First, I'd do this but as a list comprehension:

  expected_list = [
"%s,%s,%s:%s" % elements
for elements in list_tuple
]

Second, it might add greater clarity (and allow for easier
reformatting) if you give names to them:

  expected_list = [
"%i,%i,%i:%i" % (
  index,
  count,
  timestamp,
  weight,
  )
for index, count, timestamp, weight in list_tuple
]

That way, if you wanted to remove some of the items from formatting
or change their order, it's much easier.

Since your elements seem to be in the order you want to assemble them
and you are using *all* of the elements, I'd go with the first one.
But if you need to change things up (either omitting fields or
changing the order), I'd switch to the second version.

-tkc



-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Calling Matlab (2016a) function from Python(3.6)

[Bob van der Poel]

You might have better mileage using the python path routines to create
the path/file names. Set the path the routines documented in
os.path().

On Wed, Mar 28, 2018 at 10:24 PM, Rishika Sen  wrote:
> error persists
 h.Execute ("run('H:\\rishika\\MATLAB\\filewrite.m')")
> '??? Error using run (line 41)\nH:\\rishika\\MATLAB\\filewrite.m not 
> found.\n\n'
 h.Execute ("run(r'H:\rishika\MATLAB\filewrite.m')")
> '??? Error: Unexpected MATLAB expression.\n\n
> --
> https://mail.python.org/mailman/listinfo/python-list



-- 

 Listen to my FREE CD at http://www.mellowood.ca/music/cedars 
Bob van der Poel ** Wynndel, British Columbia, CANADA **
EMAIL: b...@mellowood.ca
WWW:   http://www.mellowood.ca
-- 
https://mail.python.org/mailman/listinfo/python-list

netcdf 4 error

[jorge . conrado]

Hi,

Here are some information of my netcdf4 data:

NetCDF dimension information:
Name: lon
size: 4320
type: dtype('float64')
Name: lat
size: 2160
type: dtype('float64')
Name: time
size: 12
type: dtype('float64')
NetCDF variable information:
Name: satellites
dimensions: (u'time',)
size: 12
type: dtype('int16')
Name: ndvi
dimensions: (u'time', u'lat', u'lon')
size: 111974400
type: dtype('int16')
units: u'1'
scale: u'x 1'
missing_value: -5000.0
valid_range: array([-0.3,  1. ])
Name: percentile
dimensions: (u'time', u'lat', u'lon')
size: 111974400
type: dtype('int16')
units: u'%'
scale: u'x 10'
flags: u'flag 0: from dataflag 1: spline 
interpolation flag 2: possible snow/cloud cover'

valid_range: u'flag*2000 + [0 1000]'




then I use to read my data:



nc_f = './ndvi3g_geo_v1_1981_0712.nc4'

nc_fid = nc4.Dataset(nc_f,'r')

nc_attrs, nc_dims, nc_vars = ncdump(nc_fid)

print ()

# EXTRAI AS VARIAVEIS DO ARQUIVO NETCDF

lats = nc_fid.variables['lat'][:]
lons = nc_fid.variables['lon'][:]
time = nc_fid.variables['time'][:]


ndvi1 = nc_fid.variables['ndvi'][:]


But, I had this message:


lerndvias1.py:98: UserWarning: WARNING: valid_range not used since it
cannot be safely cast to variable data type
  ndvi1 = nc_fid.variables['ndvi'][:]


Please, what can I do to solve this.


Thanks,


Conrado
--
https://mail.python.org/mailman/listinfo/python-list

Re: please test the new PyPI (now in beta)

[Sumana Harihareswara]

On Wednesday, March 28, 2018 at 10:48:52 AM UTC-4, Ethan Furman wrote:
> The new PyPI lists of projects wastes too much space, and the bright blue is 
> intolerable.  I can't use it.

As I think you know, I'm tracking the condensed view request in 
https://github.com/pypa/warehouse/issues/1988 .

When you say the bright blue is intolerable, I presume it hurts your eyes -- is 
that right? Color calibration varies across monitors, some people are sensitive 
to certain shades of light, etc., so I want to let the designer know more, and 
ask about it in user testing. You probably know that, in a real pinch, you can 
turn off styling entirely for a site in your browser, but I would prefer that 
you not have to do that.

> Are the little boxes replaceable by the package authors?  That would be 
> interesting.
> 
> --
> ~Ethan~

I think you're talking about https://github.com/pypa/warehouse/issues/2211 - 
if/when we implement that, project logo images could show up on the project 
detail pages, and in search results and similar listings, instead of the white 
cube.

-Sumana Harihareswara
Warehouse project manager
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: please test the new PyPI (now in beta)

[Ethan Furman]

On 03/29/2018 11:01 AM, Sumana Harihareswara wrote:

On Wednesday, March 28, 2018 at 10:48:52 AM UTC-4, Ethan Furman wrote:



The new PyPI lists of projects wastes too much space, and the bright blue

>> is intolerable.  I can't use it.


When you say the bright blue is intolerable, I presume it hurts your eyes

> -- is that right?

That is correct.


Color calibration varies across monitors, some people are sensitive to

> certain shades of light, etc., so I want to let the designer know more,
> and ask about it in user testing.

For me it's a matter of brightness; bright colors should be used as accents, 
not as the main course.
(IMHO, of course ;)


You probably know that, in a real pinch, you can turn off styling entirely

> for a site in your browser, but I would prefer that you not have to do that.

I am vaguely aware of that, but my typical response to such web sites is to not 
use them.


Are the little boxes replaceable by the package authors?  That would be
interesting.


I think you're talking about https://github.com/pypa/warehouse/issues/2211 -

> if/when we implement that, project logo images could show up on the project
> detail pages, and in search results and similar listings, instead of the
> white cube.

Cool, looking forward to it!

--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list

Re: please test the new PyPI (now in beta)

[Bill Deegan]

Re color.
Would the python.org background color (which is darker) work?
To my eyes the background on pypi looks like the highlight color on
python.org
(I've said this earlier, but just curious if that's what others see as well)


On Thu, Mar 29, 2018 at 2:33 PM, Ethan Furman  wrote:

> On 03/29/2018 11:01 AM, Sumana Harihareswara wrote:
>
>> On Wednesday, March 28, 2018 at 10:48:52 AM UTC-4, Ethan Furman wrote:
>>
>
> The new PyPI lists of projects wastes too much space, and the bright blue
>>>
>> >> is intolerable.  I can't use it.
>
>>
>> When you say the bright blue is intolerable, I presume it hurts your eyes
>>
> > -- is that right?
>
> That is correct.
>
> Color calibration varies across monitors, some people are sensitive to
>>
> > certain shades of light, etc., so I want to let the designer know more,
> > and ask about it in user testing.
>
> For me it's a matter of brightness; bright colors should be used as
> accents, not as the main course.
> (IMHO, of course ;)
>
> You probably know that, in a real pinch, you can turn off styling entirely
>>
> > for a site in your browser, but I would prefer that you not have to do
> that.
>
> I am vaguely aware of that, but my typical response to such web sites is
> to not use them.
>
> Are the little boxes replaceable by the package authors?  That would be
>>> interesting.
>>>
>>
>> I think you're talking about https://github.com/pypa/wareho
>> use/issues/2211 -
>>
> > if/when we implement that, project logo images could show up on the
> project
> > detail pages, and in search results and similar listings, instead of the
> > white cube.
>
> Cool, looking forward to it!
>
>
> --
> ~Ethan~
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: please test the new PyPI (now in beta)

[Ethan Furman]

On 03/29/2018 11:55 AM, Bill Deegan wrote:

Re color.
Would the python.org  background color (which is darker) 
work?
To my eyes the background on pypi looks like the highlight color on python.org 

(I've said this earlier, but just curious if that's what others see as well)


The python.org color scheme is tolerable.  ;)

--
~Ethan~

--
https://mail.python.org/mailman/listinfo/python-list

Re: issues when buidling python3.* on centos 7

[joseph pareti]

thank you so much. here's more detail on my troubleshooting.

-

STARTING POINT:
https://github.com/google/FluidNet


as shown in the readme files, the deployment calls for the following step:

cd FluidNet/manta/build
./manta ../scenes/_trainingData.py --dim 3 --addModelGeometry True
--addSphereGeometry True

The above command should produce the training data, so that torch will work
on it to train the deep network.

However, it fails due to incompatibilities of python 2.7 and 3.x; the
problem is described in:

https://stackoverflow.com/questions/49296737/invalid-syntax-in-python-function

The option of removing python constructs that are only supported in python
3 is not successful because there are more dependencies than just a couple
of statements, namely in the Simplified Wrapper Interface Generator (or
SWIG) which assumes python3.

Therefore, I need a python 3 environment. STEPS:

sudo yum -y install https://centos7.iuscommunity.org/ius-release.rpm
sudo yum shell
  remove python36-3.6.3-7.el7.x86_64
  remove python36-libs-3.6.3-7.el7.x86_64
  install python36u-3.6.4-1.ius.centos7.x86_64
  install python36u-libs-3.6.4-1.ius.centos7.x86_64
  run

[joepareti54@xxx ~]$ sudo yum install python36u
Loaded plugins: fastestmirror, langpacks
Loading mirror speeds from cached hostfile
 * epel: epel.mirror.wearetriple.com
 * ius: mirror.amsiohosting.net
Package python36u-3.6.4-1.ius.centos7.x86_64 already installed and latest
version
Nothing to do
[joepareti54@xxx ~]$

ASSUMING python36 is now fine, so moving to the next step.

sudo yum -y install python36u-pip
sudo yum install python36u-devel

>From here on, it's manta-application specific:

cmake .. -DGUI='OFF' >> cmake-10.log 2>&1
make -j8 >> make-10.log 2>&1
./manta ../scenes/_trainingData.py --dim 3 --addModelGeometry True
--addSphereGeometry True

Version: mantaflow 64bit fp1 commit
dd3bb0c0a65cc531d3c33487bde5edcb4aa6784f from Mar 29 2018, 15:21:34
Loading script '../scenes/_trainingData.py'
Traceback (most recent call last):
  File "../scenes/_trainingData.py", line 13, in 
from voxel_utils import VoxelUtils
  File "/home/joepareti54/FluidNet/manta/scenes/voxel_utils.py", line 1, in

import numpy as np
ModuleNotFoundError: No module named 'numpy'
Script finished.

cmake options are specified in the CMakeCache.txt file, and those can be
edited to select the right python environment as explained in:

https://stackoverflow.com/questions/15291500/i-have-2-versions-of-python-installed-but-cmake-is-using-older-version-how-do

In my case i have following settings:

joepareti54@xxx build]$ cat CMakeCache.txt | grep -i python

//Compile without python support (limited functionality!)

PYTHON_EXECUTABLE:FILEPATH=/usr/bin/python3.6m

PYTHON_INCLUDE_DIR:PATH=/usr/include/python3.6m

PYTHON_LIBRARY:FILEPATH=/usr/lib64/libpython3.6m.so

FIND_PACKAGE_MESSAGE_DETAILS_PythonLibs:INTERNAL=[/usr/lib64/
libpython3.6m.so][/usr/include/python3.6m][v3.6.4()]


I don't see why manta cannot find numpy, because python does find it:

[joepareti54@xxx ~]$ python
Python 3.5.2 |Anaconda 4.3.0 (64-bit)| (default, Jul  2 2016, 17:53:06)
[GCC 4.4.7 20120313 (Red Hat 4.4.7-1)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import numpy
>>>
[joepareti54@xxx ~]$

Also note that system wide python 2.7 is still there, and it is required by
centos:

[joepareti54@xxx ~]$ ls -l /usr/bin/python
lrwxrwxrwx. 1 root root 18 Mar 29 08:00 /usr/bin/python ->
/usr/bin/python2.7
[joepareti54@xxx ~]$


In addition:
[joepareti54@xxx build]$ python3.6 -V
Python 3.6.3
[joepareti54@xxx build]$ which python
/anaconda/envs/py35/bin/python
[joepareti54@xxx build]$ file /anaconda/envs/py35/bin/python
/anaconda/envs/py35/bin/python: symbolic link to `python3.5'
[joepareti54@xxx build]$ ls -l /anaconda/envs/py35/bin/python
lrwxrwxrwx. 1 root root 9 Nov 10  2016 /anaconda/envs/py35/bin/python ->
python3.5
[joepareti54@xxx build]$ ls -l /usr/bin/python
lrwxrwxrwx. 1 root root 18 Mar 29 08:00 /usr/bin/python ->
/usr/bin/python2.7
[joepareti54@xxx build]$

CONCLUSION

In summary, I don't know whether this configuration is consistent or not
for building the manta application, and whether the python set-up is
consistent.
Also to be noted that the manta application was built by the authors on an
ubuntu platform, so my work is an adaption to centos



2018-03-27 4:07 GMT+02:00 Michael Torrie :

> On 03/25/2018 10:15 AM, joseph pareti wrote:
> > The following may give a clue because of inconsistent python versions:
> >
> > [joepareti54@xxx ~]$ python -V
> > Python 3.5.2 :: Anaconda 4.3.0 (64-bit)
>
> What does 'which python' return?  As Joseph said, hopefully you didn't
> overwrite /usr/bin/python with Python 3.5.  If you did, you're hosed.
> You'll probably have to reinstall.  Python 2.7 is required by just about
> everything on CentOS 7.
>
> If you want to use Python 3.4, install it via Software Collections
> Library.  https://www.softwarecollections.org/en/
>
> To use SCL,

Re: Distributing Python virtual environments

[Dan Stromberg]

On Thu, Mar 29, 2018 at 7:06 AM, Malcolm Greene  wrote:
> We're using virtual environments with Python 3.6. Since all our pip
> installed modules are in our environment's local site-packages folder,
> is the distribution of a virtual environment as simple as recursively
> zipping the environment's root folder and distributing that archive to
> another machine running the same OS and same version of Python? The
> reason we would go this route vs downloading dependencies from a
> requirements.txt file is that the target machines may be in a private
> subnet with minimal access to the internet.

Some folks choose to set up their own pypi mirror for this kind of situation.

More info: 
https://stackoverflow.com/questions/557462/how-do-i-use-easy-install-and-buildout-when-pypi-is-down
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to apply LR over gridded time series datasets ?

[Dan Stromberg]

On Wed, Mar 28, 2018 at 7:18 PM,   wrote:
> Hello all,
>
> This code is written for multivariate (multiple independent variables 
> x1,x2,x3..xn and a dependent variable y) time series analysis using logistic 
> regression (correlation and prediction).

> This code is based on one point location (one lat/long) datasets. Suppose, I 
> am having gridded datasets (which has many points/locations, lat/long, 
> varying in space and time) then How I will implement this code. I am not 
> expertise in python. If somebody can help me in this? If somebody can give me 
> an example or idea so I can implement this code as per my requirement.

Hi Vishu.

I'm a total newbie to this kind of computing, but you might do well to
add some x's for the related data (EG, when analyzing pictures, you
flatten out the RGB triples - so if you had 64 pixels, you might have
3*64 x's), and then perhaps use additional layers to make it Deep
Learning rather than just logistic regression.

I've been looking with interest at Scikit Flow.  It's supposed to make
TensorFlow as simple for some things as Scikit Learn is.

HTH
-- 
https://mail.python.org/mailman/listinfo/python-list

[RELEASE] Python 3.7.0b3 is now available for testing

[Ned Deily]

On behalf of the Python development community and the Python 3.7 release
team, I'm happy to announce the availability of Python 3.7.0b3.  b3 is
the third of four planned beta releases of Python 3.7, the next major
release of Python, and marks the end of the feature development phase
for 3.7.  You can find Python 3.7.0b3 here:

https://www.python.org/downloads/release/python-370b3/

Among the new major new features in Python 3.7 are:

* PEP 538, Coercing the legacy C locale to a UTF-8 based locale
* PEP 539, A New C-API for Thread-Local Storage in CPython
* PEP 540, UTF-8 mode
* PEP 552, Deterministic pyc
* PEP 553, Built-in breakpoint()
* PEP 557, Data Classes
* PEP 560, Core support for typing module and generic types
* PEP 562, Module __getattr__ and __dir__
* PEP 563, Postponed Evaluation of Annotations
* PEP 564, Time functions with nanosecond resolution
* PEP 565, Show DeprecationWarning in __main__
* PEP 567, Context Variables

Please see "What’s New In Python 3.7" for more information.
Additional documentation for these features and for other changes
will be provided during the beta phase.

https://docs.python.org/3.7/whatsnew/3.7.html

Beta releases are intended to give you the opportunity to test new
features and bug fixes and to prepare their projects to support the
new feature release. We strongly encourage you to test your projects
with 3.7 during the beta phase and report issues found to
https://bugs.python.org as soon as possible.

While the release is feature complete entering the beta phase, it is
possible that features may be modified or, in rare cases, deleted up
until the start of the release candidate phase (2018-05-21). Our goal
is have no ABI changes after beta 3 and no code changes after rc1.
To achieve that, it will be extremely important to get as much exposure
for 3.7 as possible during the beta phase.

Attention macOS users: there is a new installer variant for
macOS 10.9+ that includes a built-in version of Tcl/Tk 8.6. This
variant is expected to become the default version when 3.7.0 releases.
Check it out! We welcome your feedback.  As of 3.7.0b3, the legacy
10.6+ installer also includes a built-in Tcl/Tk 8.6.

Please keep in mind that this is a preview release and its use is
not recommended for production environments.

The next planned release of Python 3.7 will be 3.7.0b4, currently
scheduled for 2018-04-30. More information about the release schedule
can be found here:

https://www.python.org/dev/peps/pep-0537/

--
  Ned Deily
  n...@python.org -- []

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Calling Matlab (2016a) function from Python(3.6)

[Michael Torrie]

On 03/28/2018 11:24 PM, Rishika Sen wrote:
> I tried these options too as suggested by Paul...
> 
 h.Execute ("run('H:\\rishika\\MATLAB\\filewrite.m')")
> '??? Error using run (line 41)\nH:\\rishika\\MATLAB\\filewrite.m not 
> found.\n\n'

Crazy question, but you're sure of that path?

 h.Execute ("run(r'H:\rishika\MATLAB\filewrite.m')")
> '??? Error: Unexpected MATLAB expression.\n\n

Not surprised there. MATLAB doesn't know what to do with the extra r you
put in there. The r expression should be added to the python string, not
the bit inside.

h.Execute(r"run('H:\rishika\MATLAB\filewrite.m')")
 

You might also try using forwards slashes for folder delimiters. All
windows APIs can deal with them.

h.Execute("run('H:/rishika/MATLAB/filewrite.m')")



-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Distributing Python virtual environments

[dieter]

Malcolm Greene  writes:

> We're using virtual environments with Python 3.6. Since all our pip
> installed modules are in our environment's local site-packages folder,
> is the distribution of a virtual environment as simple as recursively
> zipping the environment's root folder and distributing that archive to
> another machine running the same OS and same version of Python?

This may not be sufficient: at least the "bin/activate" contains
an absolute path; this implies that it cannot be relocated.

-- 
https://mail.python.org/mailman/listinfo/python-list

Regex Doubts

[Iranna Mathapati]

Hi Team,


how to achieve fallowing expected output?

str_output= """

MOD1 memory  : 2 valid1790 free
MOD2 memory  : 128 valid   128 free
UDP Aware *MEMR*: 0 valid   0 free *MEMR
   : 21 valid   491 free
https://mail.python.org/mailman/listinfo/python-list