Re: Error: thrift.transport.TTransport.TTransportException: Could not start SASL: b'Error in sasl_client_start (-4) SASL(-4): no mechanism available: Unable t

[cdarlint]

On Friday, October 11, 2019 at 6:27:40 PM UTC+8, prabakar...@gmail.com wrote:
> python> conn = 
> hive.Connection(host="xx.xx.xxx.xxx",port=8889,username='hadoop')
> 
> C:\Users\Nova15>python
> Python 3.7.4 (tags/v3.7.4:e09359112e, Jul  8 2019, 20:34:20) [MSC v.1916 64 
> bit (AMD64)] on win32
> Type "help", "copyright", "credits" or "license" for more information.
> >>> from pyhive import hive
> >>> conn = hive.Connection(host="54.169.219.144",port=8889,username='hadoop')
> Traceback (most recent call last):
>   File "", line 1, in 
>   File 
> "c:\users\nova15\appdata\local\programs\python\python37\lib\site-packages\pyhive\hive.py",
>  line 192, in __init__
> self._transport.open()
>   File 
> "c:\users\nova15\appdata\local\programs\python\python37\lib\site-packages\thrift_sasl\__init__.py",
>  line 79, in open
> message=("Could not start SASL: %s" % self.sasl.getError()))
> thrift.transport.TTransport.TTransportException: Could not start SASL: 
> b'Error in sasl_client_start (-4) SASL(-4): no mechanism available: Unable to 
> find a callback: 2'
> 
> 
> I am trying to connect from windows 10 local to Prestodb in AWS.

I've worked out some steps to make it work
basically it needs to find sasl2 folder, which located site-library/sasl(pip) 
or Library/bin(conda)
method 1: put sasl2 folder into C:\CMU\bin\
method 2: add an entry in registry, to the sasl2 folder, e.g.
HKEY_LOCAL_MACHINE\SOFTWARE\Carnegie Mellon\Project Cyrus\SASL 
Library\SearchPath
C:\Users\cdarling\Miniconda3\envs\hive\Library\bin\sasl2

I've replied related github issue too
https://github.com/dropbox/PyHive/issues/161
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Installation problem

[cdarlint]

On Monday, May 11, 2020 at 9:56:17 AM UTC+8, Solomon Onuche Faruna wrote:
> I install python 3.8 and pycharm community edition on window 8 but when I
> try to install matplotlib in pycharm I discovered I got  "error loading
> package list pypi.python.org" so I updated the pycharm to version 2020.1.
> The packages loaded but when I try to install matplotlib I was told "No
> matching distribution found for matplotlib". I am confused right now. I
> need urgent help. Thanks

I would suggest you to install Anaconda which include python/numpy and possibly 
matplotlib altogether
if not included, just run in cmd:
conda install matplotlib
and it will be installed
-- 
https://mail.python.org/mailman/listinfo/python-list

scikit learn problem

[pariisaap]

Hello
I tried to run a pickle and after that i couldn't to run any program containing 
sklearn 
I uninstall python and install again but i still have problem with scikit learn 
can anybody help me . thank you.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: scikit learn problem

[pariisaap]

On Monday, 11 May 2020 19:11:59 UTC+4:30, pari...@gmail.com  wrote:
> Hello
> I tried to run a pickle code and after that i couldn't run any program 
> containing sklearn 
> I uninstall python and install again but i still have problem with scikit 
> learn can anybody help me . thank you.
the error is something like that


"Traceback (most recent call last):
  File "C:/Users/Rah/Desktop/python/sckitlearn/6.py", line 1, in 
from sklearn.linear_model import LogisticRegression
  File 
"C:\Users\Rah\AppData\Local\Programs\Python\Python37\lib\site-packages\sklearn\__init__.py",
 line 76, in 
from .base import clone"

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

Re: scikit learn problem

[pariisaap]

On Monday, 11 May 2020 19:11:59 UTC+4:30, pari...@gmail.com  wrote:
> Hello
> I tried to run a pickle and after that i couldn't  run any program containing 
> sklearn 
> I uninstall python and install again but i still have problem with scikit 
> learn can anybody help me . thank you.
the error is something like that


"Traceback (most recent call last):
  File "C:/Users/Rah/Desktop/python/sckitlearn/6.py", line 1, in 
from sklearn.linear_model import LogisticRegression
  File 
"C:\Users\Rah\AppData\Local\Programs\Python\Python37\lib\site-packages\sklearn\__init__.py",
 line 76, in 
from .base import clone"

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

Re: scikit learn problem

[Souvik Dutta]

Is that the complete error message?

On Mon, 11 May, 2020, 8:25 pm ,  wrote:

> On Monday, 11 May 2020 19:11:59 UTC+4:30, pari...@gmail.com  wrote:
> > Hello
> > I tried to run a pickle and after that i couldn't  run any program
> containing sklearn
> > I uninstall python and install again but i still have problem with
> scikit learn can anybody help me . thank you.
> the error is something like that
>
>
> "Traceback (most recent call last):
>   File "C:/Users/Rah/Desktop/python/sckitlearn/6.py", line 1, in
> 
> from sklearn.linear_model import LogisticRegression
>   File
> "C:\Users\Rah\AppData\Local\Programs\Python\Python37\lib\site-packages\sklearn\__init__.py",
> line 76, in 
> from .base import clone"
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: scikit learn problem

[MRAB]

On 2020-05-11 16:23, Souvik Dutta wrote:

Is that the complete error message?

It's a strange traceback because it shows a path with slashes (on 
Windows?) and a path with backslashes.



On Mon, 11 May, 2020, 8:25 pm ,  wrote:


On Monday, 11 May 2020 19:11:59 UTC+4:30, pari...@gmail.com  wrote:
> Hello
> I tried to run a pickle and after that i couldn't  run any program
containing sklearn
> I uninstall python and install again but i still have problem with
scikit learn can anybody help me . thank you.
the error is something like that


"Traceback (most recent call last):
  File "C:/Users/Rah/Desktop/python/sckitlearn/6.py", line 1, in

from sklearn.linear_model import LogisticRegression
  File
"C:\Users\Rah\AppData\Local\Programs\Python\Python37\lib\site-packages\sklearn\__init__.py",
line 76, in 
from .base import clone"

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





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

Re: Installation problem

[Mats Wichmann]

On 5/10/20 3:31 PM, Solomon Onuche Faruna wrote:
> I install python 3.8 and pycharm community edition on window 8 but when I
> try to install matplotlib in pycharm I discovered I got  "error loading
> package list pypi.python.org" so I updated the pycharm to version 2020.1.
> The packages loaded but when I try to install matplotlib I was told "No
> matching distribution found for matplotlib". I am confused right now. I
> need urgent help. Thanks
> 

The message normally means either the architecture or the python version
is not available in a package uploaded to pypi. It doesn't sound like
the version is the problem at least - you're trying 3.8 and matplotlib
now has 3.8 packages.

pypi access, meanwhile, may have some problems if you're having to go
through a proxy for your network connection - it doesn't use the one set
up for your web browser.

https://pip.pypa.io/en/stable/user_guide/

Just a couple of things to think about...

The advice you've already received to get a unified environment through
Anaconda is a good one.  It was created largely for that reason -
getting numpy, scipy, matplotlib, etc. all installed can be a daunting
task if you're new to the Python package world.

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

proposal for slice hashing

[Will Bradshaw]

I recently ran into a situation where I needed to hash a slice and found this 
to be unsupported. This seems silly as there is little benefit of slices not 
supporting hashing and large downsides.  This coupled with the fact that one 
cannot subclass slices is a significant and needless annoyance.

It seems to me a hash of a slices would simply be a hash of a slice would (in 
python) be:
def __hash__(self):
return hash((self.start, self.stop, self.step))
I can see no reason why this is not the case


Context:

I have an object that presents itself as a multidimensional array in the numpy 
style but is computes it's values on __getitem__ calls as it represents an 
infinite field of numbers. However this operation is expensive. In many cases 
the same slice of the field will be needed repeatedly. This lends itself to 
using an lru cache on __getitem__() however this does not work as slices cannot 
be stored in the dictionary key used for the lru_cache.*


The only options as of now are:
1. use 3 layers of wrappers to pack the slices into a custom type that 
supports hashing pass this mangled version of the arguments through lru_cache 
wrapper into a function that reverses the process of the first wrapper and 
passes through to the underlying implementation. (see below "code for 
workaround" as example)
   - This is kinda jank and arguably slow. Though in my case the cost of 
the calculation operation dwarfs this cost by an several orders of magnitude.
   - mapping may be unreliable and is a rather long and impenetrable mess. 
2. implementing my own custom caching for this situation which does not 
scale well and is a heck of a lot of work.
3. implement a special case for slices in the lru_cache function. However, 
this is just moving the problem into the functools library.


* While I do realize that further efficiency gains would be found by caching 
results in a sparse and tracking what is and is not filled in the field thus 
keeping what is essentially a by cell cache that would be significantly more 
work and unlikely to yield much better results in my case and still doesn't 
solve the general use case.


Code for Workaround:

from functools import lru_cache


class _hashable_slice(object):
__slots__ = ['slice']

def __init__(self, s: slice):
self.slice = s

def __hash__(self):
return hash((self.slice.start, self.slice.stop, self.slice.step))

def __eq__(self, other):
return other == self.slice


def slice_lru_cache(*lru_args, **lru_kwargs):
lru_wrapper = lru_cache(*lru_args, **lru_kwargs)

def decorator(f):
@lru_wrapper
def inner(*args, **kwargs):
def unpack(x):
if isinstance(x, _hashable_slice):
return x.slice
if isinstance(x, (tuple, list)):
return type(x)(unpack(v) for v in x)
else:
return x

return f(*(unpack(v) for v in args),
 **{k: unpack(v) for k, v in kwargs.items()})

def wrapper(*args, **kwargs):
def pack(x):
if isinstance(x, slice):
return _hashable_slice(x)
if isinstance(x, (tuple, list)):
return type(x)(pack(v) for v in x)
else:
return x
return inner(*(pack(v) for v in args),
 **{k: pack(v) for k, v in kwargs.items()})
wrapper.__getattr__ = lambda name: getattr(inner, name)
return wrapper
return decorator
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: proposal for slice hashing

[Chris Angelico]

On Tue, May 12, 2020 at 6:01 AM Will Bradshaw  wrote:
> The only options as of now are:
> 1. use 3 layers of wrappers to pack the slices into a custom type that 
> supports hashing pass this mangled version of the arguments through lru_cache 
> wrapper into a function that reverses the process of the first wrapper and 
> passes through to the underlying implementation. (see below "code for 
> workaround" as example)
>- This is kinda jank and arguably slow. Though in my case the cost of 
> the calculation operation dwarfs this cost by an several orders of magnitude.
>- mapping may be unreliable and is a rather long and impenetrable mess.
> 2. implementing my own custom caching for this situation which does not 
> scale well and is a heck of a lot of work.
> 3. implement a special case for slices in the lru_cache function. 
> However, this is just moving the problem into the functools library.
>

4. Implement __getitem__ as a wrapper around a caching lookup function
that simply takes the three arguments.

def __getitem__(self, slice):
return generate_values(slice.start, slice.stop, slice.step)

@lru_cache
def generate_values(start, stop, step):
...

Not sure if this makes it easy enough to not worry about the hashability.

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

Re: proposal for slice hashing

[Will Bradshaw]

On Monday, May 11, 2020 at 4:10:56 PM UTC-4, Chris Angelico wrote:
> On Tue, May 12, 2020 at 6:01 AM Will Bradshaw  wrote:
> > The only options as of now are:
> > 1. use 3 layers of wrappers to pack the slices into a custom type that 
> > supports hashing pass this mangled version of the arguments through 
> > lru_cache wrapper into a function that reverses the process of the first 
> > wrapper and passes through to the underlying implementation. (see below 
> > "code for workaround" as example)
> >- This is kinda jank and arguably slow. Though in my case the cost 
> > of the calculation operation dwarfs this cost by an several orders of 
> > magnitude.
> >- mapping may be unreliable and is a rather long and impenetrable 
> > mess.
> > 2. implementing my own custom caching for this situation which does not 
> > scale well and is a heck of a lot of work.
> > 3. implement a special case for slices in the lru_cache function. 
> > However, this is just moving the problem into the functools library.
> >
> 
> 4. Implement __getitem__ as a wrapper around a caching lookup function
> that simply takes the three arguments.
> 
> def __getitem__(self, slice):
> return generate_values(slice.start, slice.stop, slice.step)
> 
> @lru_cache
> def generate_values(start, stop, step):
> ...
> 
> Not sure if this makes it easy enough to not worry about the hashability.
> 
> ChrisA

does not work in the case of multi dimensional __getitem__ calls in the numpy 
style which happens to be my case as the number of dimensions in the indexes 
changes by case and all of the following are supported for each axis: slice, 
array of indexes, int index, and other custom index object types which I am 
hesitant to disclose)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: proposal for slice hashing

[Chris Angelico]

On Tue, May 12, 2020 at 6:31 AM Will Bradshaw  wrote:
>
> On Monday, May 11, 2020 at 4:10:56 PM UTC-4, Chris Angelico wrote:
> > On Tue, May 12, 2020 at 6:01 AM Will Bradshaw  
> > wrote:
> > > The only options as of now are:
> > > 1. use 3 layers of wrappers to pack the slices into a custom type 
> > > that supports hashing pass this mangled version of the arguments through 
> > > lru_cache wrapper into a function that reverses the process of the first 
> > > wrapper and passes through to the underlying implementation. (see below 
> > > "code for workaround" as example)
> > >- This is kinda jank and arguably slow. Though in my case the cost 
> > > of the calculation operation dwarfs this cost by an several orders of 
> > > magnitude.
> > >- mapping may be unreliable and is a rather long and impenetrable 
> > > mess.
> > > 2. implementing my own custom caching for this situation which does 
> > > not scale well and is a heck of a lot of work.
> > > 3. implement a special case for slices in the lru_cache function. 
> > > However, this is just moving the problem into the functools library.
> > >
> >
> > 4. Implement __getitem__ as a wrapper around a caching lookup function
> > that simply takes the three arguments.
> >
> > def __getitem__(self, slice):
> > return generate_values(slice.start, slice.stop, slice.step)
> >
> > @lru_cache
> > def generate_values(start, stop, step):
> > ...
> >
> > Not sure if this makes it easy enough to not worry about the hashability.
> >
> > ChrisA
>
> does not work in the case of multi dimensional __getitem__ calls in the numpy 
> style which happens to be my case as the number of dimensions in the indexes 
> changes by case and all of the following are supported for each axis: slice, 
> array of indexes, int index, and other custom index object types which I am 
> hesitant to disclose)
>

Ah, fair enough. Was just looking for a solution that would work on
existing Python versions rather than demanding an upgrade to 3.10 :)

Your use-case isn't common, but on the other hand, making slice
objects hashable doesn't seem like it'd break anything. Obviously
they'd only be hashable if start/stop/step are all hashable, but
that's no different from tuples. +0.5.

BTW, your third option (moving the problem to functools) might
actually be easier than you think. You'd ultimately just be changing
the behaviour of _make_key. Unfortunately there's no easy way to
replace that function for a specific lru_cache, but that might itself
be a useful feature. Imagine this:

@lru_cache(make_key=hashable_slices)
def __getitem__(self, item):
...

Current implementation has a single global _make_key function that
then gets snapshotted into the closure, so you could do something
hacky as a proof of concept:

old = functools._make_key
functools._make_key = hashable_slices
@lru_cache
def __getitem__(self, item):
...
functools._make_key = old

Obviously that's bad code, but it's a great low-effort proof of concept :)

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

Re: proposal for slice hashing

[Will Bradshaw]

On Monday, May 11, 2020 at 4:45:55 PM UTC-4, Chris Angelico wrote:
> On Tue, May 12, 2020 at 6:31 AM Will Bradshaw  wrote:
> >
> > On Monday, May 11, 2020 at 4:10:56 PM UTC-4, Chris Angelico wrote:
> > > On Tue, May 12, 2020 at 6:01 AM Will Bradshaw  
> > > wrote:
> > > > The only options as of now are:
> > > > 1. use 3 layers of wrappers to pack the slices into a custom type 
> > > > that supports hashing pass this mangled version of the arguments 
> > > > through lru_cache wrapper into a function that reverses the process of 
> > > > the first wrapper and passes through to the underlying implementation. 
> > > > (see below "code for workaround" as example)
> > > >- This is kinda jank and arguably slow. Though in my case the 
> > > > cost of the calculation operation dwarfs this cost by an several orders 
> > > > of magnitude.
> > > >- mapping may be unreliable and is a rather long and 
> > > > impenetrable mess.
> > > > 2. implementing my own custom caching for this situation which does 
> > > > not scale well and is a heck of a lot of work.
> > > > 3. implement a special case for slices in the lru_cache function. 
> > > > However, this is just moving the problem into the functools library.
> > > >
> > >
> > > 4. Implement __getitem__ as a wrapper around a caching lookup function
> > > that simply takes the three arguments.
> > >
> > > def __getitem__(self, slice):
> > > return generate_values(slice.start, slice.stop, slice.step)
> > >
> > > @lru_cache
> > > def generate_values(start, stop, step):
> > > ...
> > >
> > > Not sure if this makes it easy enough to not worry about the hashability.
> > >
> > > ChrisA
> >
> > does not work in the case of multi dimensional __getitem__ calls in the 
> > numpy style which happens to be my case as the number of dimensions in the 
> > indexes changes by case and all of the following are supported for each 
> > axis: slice, array of indexes, int index, and other custom index object 
> > types which I am hesitant to disclose)
> >
> 
> Ah, fair enough. Was just looking for a solution that would work on
> existing Python versions rather than demanding an upgrade to 3.10 :)

I have a solution to the issue in current python, it was given in my first post 
at the bottom. I implemented a variant of it for my work. Just because there is 
a hack does not mean a fix should not be implemented.

> Your use-case isn't common, but on the other hand, making slice
> objects hashable doesn't seem like it'd break anything. Obviously
> they'd only be hashable if start/stop/step are all hashable, but
> that's no different from tuples. +0.5.


I'm certain that my use case is not common. However, there are certainly many 
uncommon use cases in which being able to have a slice in a dictionary key or 
otherwise hashing a slice could be useful.

> 
> BTW, your third option (moving the problem to functools) might
> actually be easier than you think. You'd ultimately just be changing
> the behaviour of _make_key. Unfortunately there's no easy way to
> replace that function for a specific lru_cache, but that might itself
> be a useful feature. Imagine this:
> 
> @lru_cache(make_key=hashable_slices)
> def __getitem__(self, item):
> ...

This is a good idea as it would allow for quite a bit of tuning by the user and 
 allow trade offs to be made between cache lookup complexity and potentially 
unnecessary re-computes.
-- 
https://mail.python.org/mailman/listinfo/python-list

Help Problem with python : python-3.8.3rc1-amd64

[Buddy Peacock]

I am trying to install python on my surface with windows 10, version 1903,
build 18362.778.  The installer seems to think everything worked. But there
is no Python folder anywhere on the system.  I looked in the root directory
as well as "Program Files" and "Program Files (x86)" and not in any users
folders either.  I have uninstalled and re-installed twice.  Once after
shutting down and restarting.  Your help would be appreciated as I am
taking an on-line programming class.
Al (Buddy) Peacock, PMP, MCCT,  ITILv3, SMC, CSM, SPOC
(920) 740-3411
linkedin.com/in/buddypeacock 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Help Problem with python : python-3.8.3rc1-amd64

[Michael Torrie]

On 5/11/20 8:33 PM, Buddy Peacock wrote:
> I am trying to install python on my surface with windows 10, version 1903,
> build 18362.778.  The installer seems to think everything worked. But there
> is no Python folder anywhere on the system.  I looked in the root directory
> as well as "Program Files" and "Program Files (x86)" and not in any users
> folders either.  I have uninstalled and re-installed twice.  Once after
> shutting down and restarting.  Your help would be appreciated as I am
> taking an on-line programming class.

Unless you specifically selected "install for all users" it's probably
going to be installed to your home directory under the hidden folder
"AppData," specially "AppData\Local\Programs\Python."  Be sure to tell
the installer to put python in your path--that way no matter where it
is, from the command prompt you can just run "python" and it will fire
up the interpreter.  Additionally, "Idle" (the integrated development
environment) will probably be in your start menu.

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

Re: Help Problem with python : python-3.8.3rc1-amd64

[Michael Torrie]

On 5/11/20 9:25 PM, Michael Torrie wrote:
> On 5/11/20 8:33 PM, Buddy Peacock wrote:
>> I am trying to install python on my surface with windows 10, version 1903,
>> build 18362.778.  The installer seems to think everything worked. But there
>> is no Python folder anywhere on the system.  I looked in the root directory
>> as well as "Program Files" and "Program Files (x86)" and not in any users
>> folders either.  I have uninstalled and re-installed twice.  Once after
>> shutting down and restarting.  Your help would be appreciated as I am
>> taking an on-line programming class.
> 
> Unless you specifically selected "install for all users" it's probably
> going to be installed to your home directory under the hidden folder
> "AppData," specially "AppData\Local\Programs\Python."  Be sure to tell
> the installer to put python in your path--that way no matter where it
> is, from the command prompt you can just run "python" and it will fire
> up the interpreter.  Additionally, "Idle" (the integrated development
> environment) will probably be in your start menu.

Hmm, actually I think the AppData install path is if you install from
the Microsoft Store, which you could try.

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