Re: If you are running 32-bit 3.6 on Windows, please test this

[Pavol Lisy]

On 8/31/17, 20/20 Lab  wrote:
>
>
> On 08/31/2017 01:53 AM, Pavol Lisy wrote:
[...]
> Valid point, fired up a windows 10 machine and worked as well.
>
> Python 3.6.2 (v3.6.2:5fd33b5, Jul 8 2017, 04:14:34) [MSC v.1900 32 bit
> (Intel)] on win32
> Type "copyright", "credits" or "license()" for more information.
>  >>> import math
>  >>> math.sqrt(1.3)
> 1.140175425099138
>  >>>
>
> This machine does not have the creators update yet.  So there's that.
> --
> https://mail.python.org/mailman/listinfo/python-list

Thx! :)

Could somebody help me?

I was trying to call sqrt using ctypes from msvcrt but I am not succesful:

import ctypes
msc = ctypes.windll.msvcrt

def msqrt(arg):
s = ctypes.create_string_buffer(100)
d = ctypes.c_longdouble(arg)
msc.sprintf(s, b'arg = %g', d)
print(s.value.decode())
r = msc.sqrt(d)
msc.sprintf(s, b'sqrt = %g', r)   # r is int so this format is
wrong I just like to show my intention
print(s.value.decode())
print("r = ", r, r.__class__)

>>> msqrt(1.3)
arg = 1.3
sqrt = 0
r =  0 

>>> msqrt(-1)
arg = -1
sqrt = 4.00144e-320   # because wrong format in sprintf
r =  8099 

And ->

>>> msc.sqrt.restype
ctypes.c_long

>>> msc.sqrt.argtypes is None
True

How to do it properly? Isn't ctypes broken?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: If you are running 32-bit 3.6 on Windows, please test this

[Peter Otten]

Pavol Lisy wrote:

> On 8/31/17, 20/20 Lab  wrote:
>>
>>
>> On 08/31/2017 01:53 AM, Pavol Lisy wrote:
> [...]
>> Valid point, fired up a windows 10 machine and worked as well.
>>
>> Python 3.6.2 (v3.6.2:5fd33b5, Jul 8 2017, 04:14:34) [MSC v.1900 32 bit
>> (Intel)] on win32
>> Type "copyright", "credits" or "license()" for more information.
>>  >>> import math
>>  >>> math.sqrt(1.3)
>> 1.140175425099138
>>  >>>
>>
>> This machine does not have the creators update yet.  So there's that.
>> --
>> https://mail.python.org/mailman/listinfo/python-list
> 
> Thx! :)
> 
> Could somebody help me?
> 
> I was trying to call sqrt using ctypes from msvcrt but I am not succesful:
> 
> import ctypes
> msc = ctypes.windll.msvcrt
> 
> def msqrt(arg):
> s = ctypes.create_string_buffer(100)
> d = ctypes.c_longdouble(arg)
> msc.sprintf(s, b'arg = %g', d)
> print(s.value.decode())
> r = msc.sqrt(d)
> msc.sprintf(s, b'sqrt = %g', r)   # r is int so this format is
> wrong I just like to show my intention
> print(s.value.decode())
> print("r = ", r, r.__class__)
> 
 msqrt(1.3)
> arg = 1.3
> sqrt = 0
> r =  0 
> 
 msqrt(-1)
> arg = -1
> sqrt = 4.00144e-320   # because wrong format in sprintf
> r =  8099 
> 
> And ->
> 
 msc.sqrt.restype
> ctypes.c_long
> 
 msc.sqrt.argtypes is None
> True
> 
> How to do it properly? Isn't ctypes broken?

I think you have to specify the types yourself:

>>> import ctypes
>>> libm = ctypes.cdll.LoadLibrary("libm.so")
>>> libm.sqrt(42)
0
>>> libm.sqrt.argtypes = [ctypes.c_double]
>>> libm.sqrt.restype = ctypes.c_double
>>> libm.sqrt(42)
6.48074069840786


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

rdflib, N-Triples and Pandas

[David Shi via Python-list]

How best to use rdflib to parse N-Triples files and turn them into Pandas 
tables?
Looking forward to hearing from you.
Regards,
David
-- 
https://mail.python.org/mailman/listinfo/python-list

Solutions Manual Test Bank for College Physics 11th Edition by Serway

[estavilloraymart]

Can i buy youre solutions manual ? 
-- 
https://mail.python.org/mailman/listinfo/python-list

how to update mongo using a dataframe for multiple documents

[Daiyue Weng]

Hi, I am trying to batch update mongo using a DataFrame,

df_dict = df[['id', 'name']].to_dict(orient='records')
[{'name': 'vendor1', 'id': '1'},
 {'name': 'vendor2', 'id': '2'},
 {'name': 'vendor3', 'id': '3'},
 {'name': 'vendor4', 'id': '4'},
 {'name': 'vendor5', 'id': '5'},
 {'name': 'vendor6', 'id': '6'},]
def update_database(update_dicts, table, database):
for row_dict in update_dicts:
database[table].update_one({'id': row_dict['id']},
{'$set': 'name': row_dict['name']})

when doing updating, pass df_dict to update_database function as the
argument for update_dicts; I am wondering is there a way to update mongo in
one go that doesn't have to go through the for loop and update_one document
at a time.

I am thinking if I don't go through the loop, it will be more efficient for
updating mongo.

I know there a Bulk.find.update() operation, one has to loop through the
list of dicts in order to initialize the Bulk() operation for each document
(using find) in order to update.

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

Re: Case-insensitive string equality

[Steve D'Aprano]

On Thu, 31 Aug 2017 08:15 pm, Rhodri James wrote:

> I'd quibble about the name and the implementation (length is not
> preserved under casefolding), 

Yes, I'd forgotten about that.

> but I'd go for this.  The number of times 
> I've written something like this in different languages...


[...]
> The only way I can think of to get much traction with this is to have a
> separate case-insensitive string class.  That feels a bit heavyweight,
> though.

You might be right about that.



-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

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

Re: Case-insensitive string equality

[Steve D'Aprano]

On Fri, 1 Sep 2017 09:53 am, MRAB wrote:

> What would you expect the result would be for:
> 
>  "\N{LATIN SMALL LIGATURE FI}".case_insensitive_find("F")
> 
>  "\N{LATIN SMALL LIGATURE FI}".case_insensitive_find("I)

That's easy. 

-1 in both cases, since neither "F" nor "I" is found in either string. We can
prove this by manually checking:

py> for c in "\N{LATIN SMALL LIGATURE FI}":
... print(c, 'F' in c, 'f' in c)
... print(c, 'I' in c, 'i' in c)
...
fi False False
fi False False


If you want some other result, then you're not talking about case sensitivity.

If anyone wants to propose "normalisation-insensitive matching", I'll ask you to
please start your own thread rather than derailing this one with an unrelated,
and much more difficult, problem.

The proposal here is *case insensitive* matching, not Unicode normalisation. If
you want to decompose the strings, you know how to:

py> import unicodedata
py> unicodedata.normalize('NFKD', "\N{LATIN SMALL LIGATURE FI}")
'fi'


-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

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

python logic

[SS]

Check out the following simple code:

#!/bin/python

print "1 - echo 1"
print "2 - echo 2"

answer = input("Enter your choice - ")

if answer == 1:
  print "1"
elif answer == 2:
  print "2"
else:
  print "Invalid choice!"


The else statement noted above works fine for numeric values other then 1 or 2. 
 But if a user types in alphanumeric data (letters) into this, it blows up.  
Check out the following:

[root@ansi ~]$ ./trash
1 - echo 1
2 - echo 2
Enter your choice - 3
Invalid choice!

[root@ansi ~]$ ./trash
1 - echo 1
2 - echo 2
Enter your choice - r
Traceback (most recent call last):
  File "./trash", line 6, in 
answer = input("Enter your choice - ")
  File "", line 1, in 
NameError: name 'r' is not defined

I would expect the same behavior from both runs.  Why does Python differ in the 
way it treats a character in that program?  Finally, how to accomodate for such 
(how to fix)?

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

Re: python logic

[eth0]

Era el Fri, 1 Sep 2017 06:30:43 -0700 (PDT) en comp.lang.python,
cuando de repente SS
dijo lo siguiente acerca de
python logic:

>  Check out the following simple code:
> 
>  #!/bin/python
> 
>  print "1 - echo 1"
>  print "2 - echo 2"
> 
>  answer = input("Enter your choice - ")
> 
>  if answer == 1:
>print "1"
>  elif answer == 2:
>print "2"
>  else:
>print "Invalid choice!"
> 
> 
>  The else statement noted above works fine for numeric values other
>  then 1 or 2.  But if a user types in alphanumeric data (letters) into
>  this, it blows up.  Check out the following:
> 
>  [root@ansi ~]$ ./trash
>  1 - echo 1
>  2 - echo 2
>  Enter your choice - 3
>  Invalid choice!
> 
>  [root@ansi ~]$ ./trash
>  1 - echo 1
>  2 - echo 2
>  Enter your choice - r
>  Traceback (most recent call last):
>File "./trash", line 6, in 
>  answer = input("Enter your choice - ")
>File "", line 1, in 
>  NameError: name 'r' is not defined
> 
>  I would expect the same behavior from both runs.  Why does Python
>  differ in the way it treats a character in that program?  Finally,
>  how to accomodate for such (how to fix)?
> 
>  TIA

In Python 2, the input() function evaluates whatever you enter in the
prompt. In your case, Python is trying to evaluate 'r' as if it was
a variable or something. Use the raw_input() function instead.

However, note that if you ever want to run your script with Python 3
you'll have to switch back to using input(), which does exactly the
same as Python 2's raw_input().
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: python logic

[Steve D'Aprano]

On Fri, 1 Sep 2017 11:30 pm, SS wrote:

> Check out the following simple code:
[...]

Did you read the documentation for the `input` function?

In Python 2, `input` should be avoided, because it evaluates whatever the user
types. Watch this:

py> answer = input('type a number ')
type a number 'abcdefg'.find('e')
py> print answer
4


What you should use is `raw_input`, but remember that it returns a string, not a
number, so if you want a number you have to call int() on the results.



-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

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

Select data in N-Triples

[David Shi via Python-list]

in a N-Triples file, there are a lot lines like the following:
 
 "Baginton E04009817"@en 
. 
 "Live" 
. 
 "E04009817" .
What I am interested is to find all lines contains something like "Baginton 
E04009817".
Then, put the name and code into corresponding cells in 2 columns.
Maybe, the solution is to find ways to select those lines having 
rdf-schema#label
Is there a good example?
Regards,
David
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Case-insensitive string equality

[Chris Angelico]

On Fri, Sep 1, 2017 at 11:22 PM, Steve D'Aprano
 wrote:
> On Fri, 1 Sep 2017 09:53 am, MRAB wrote:
>
>> What would you expect the result would be for:
>>
>>  "\N{LATIN SMALL LIGATURE FI}".case_insensitive_find("F")
>>
>>  "\N{LATIN SMALL LIGATURE FI}".case_insensitive_find("I)
>
> That's easy.
>
> -1 in both cases, since neither "F" nor "I" is found in either string. We can
> prove this by manually checking:
>
> py> for c in "\N{LATIN SMALL LIGATURE FI}":
> ... print(c, 'F' in c, 'f' in c)
> ... print(c, 'I' in c, 'i' in c)
> ...
> fi False False
> fi False False
>
>
> If you want some other result, then you're not talking about case sensitivity.

>>> "\N{LATIN SMALL LIGATURE FI}".upper()
'FI'
>>> "\N{LATIN SMALL LIGATURE FI}".lower()
'fi'
>>> "\N{LATIN SMALL LIGATURE FI}".casefold()
'fi'

Aside from lower(), which returns the string unchanged, the case
conversion rules say that this contains two letters. So "F" exists in
the uppercased version of the string, and "f" exists in the casefolded
version.

So what's the definition of "case insensitive find"? The most simple
and obvious form is:

def case_insensitive_find(self, other):
return self.casefold().find(other.casefold())

which would clearly return 0 and 1 for the two original searches.

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

Re: python logic

[Rhodri James]

On 01/09/17 14:30, SS wrote:

Check out the following simple code:

#!/bin/python

print "1 - echo 1"
print "2 - echo 2"

answer = input("Enter your choice - ")

if answer == 1:
   print "1"
elif answer == 2:
   print "2"
else:
   print "Invalid choice!"


The else statement noted above works fine for numeric values other then 1 or 2. 
 But if a user types in alphanumeric data (letters) into this, it blows up.  
Check out the following:

[root@ansi ~]$ ./trash
1 - echo 1
2 - echo 2
Enter your choice - 3
Invalid choice!

[root@ansi ~]$ ./trash
1 - echo 1
2 - echo 2
Enter your choice - r
Traceback (most recent call last):
   File "./trash", line 6, in 
 answer = input("Enter your choice - ")
   File "", line 1, in 
NameError: name 'r' is not defined

I would expect the same behavior from both runs.  Why does Python differ in the 
way it treats a character in that program?  Finally, how to accomodate for such 
(how to fix)?


You don't say, but you must be running Python 2.x.  If you fire up an 
interactive session:


rhodri@sto-helit ~ $ python
Python 2.7.12 (default, Nov 19 2016, 06:48:10)
[GCC 5.4.0 20160609] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> help(input)

Help on built-in function input in module __builtin__:

input(...)
input([prompt]) -> value

Equivalent to eval(raw_input(prompt)).

>>>

Now raw_input() just returns the string that you typed in:

>>> raw_input("Type a number:")
Type a number:3
'3'

Notice that this is a string, in quotes, not an integer.  What happens 
when we eval() that?


>>> eval('3')
3

This is the integer that you wanted.  Great.  Now how about that letter 
you typed instead?


>>> raw_input("Type a number:")
Type a number:r
'r'
>>> eval('r')
Traceback (most recent call last):
  File "", line 1, in 
  File "", line 1, in 
NameError: name 'r' is not defined

In other words, eval() looks for something named "r" but can't find 
anything, so it can't evaluate the input string.  You can prove this by 
creating something named "r" and trying again:


>>> r = 13
>>> eval('r')
13

Going back to your question, what you want to do is to use the function 
raw_input() and compare the input to the strings "1" and "2" (because 
that input is a string, remember?).  You could use the function int() to 
convert the string to an integer, but then you would have to catch the 
cases when the user types something that isn't an integer for yourself!


In Python3, it was generally agreed that the fancy behaviour of input() 
caused more confusion than it was worth.  input() in Python3 behaves 
like raw_input() in Python2, just returning the characters typed in as a 
string.


--
Rhodri James *-* Kynesim Ltd
--
https://mail.python.org/mailman/listinfo/python-list

Re: python logic

[SS]

On Friday, September 1, 2017 at 9:32:16 AM UTC-4, SS wrote:
> Check out the following simple code:
> 
> #!/bin/python
> 
> print "1 - echo 1"
> print "2 - echo 2"
> 
> answer = input("Enter your choice - ")
> 
> if answer == 1:
>   print "1"
> elif answer == 2:
>   print "2"
> else:
>   print "Invalid choice!"
> 
> 
> The else statement noted above works fine for numeric values other then 1 or 
> 2.  But if a user types in alphanumeric data (letters) into this, it blows 
> up.  Check out the following:
> 
> [root@ansi ~]$ ./trash
> 1 - echo 1
> 2 - echo 2
> Enter your choice - 3
> Invalid choice!
> 
> [root@ansi ~]$ ./trash
> 1 - echo 1
> 2 - echo 2
> Enter your choice - r
> Traceback (most recent call last):
>   File "./trash", line 6, in 
> answer = input("Enter your choice - ")
>   File "", line 1, in 
> NameError: name 'r' is not defined
> 
> I would expect the same behavior from both runs.  Why does Python differ in 
> the way it treats a character in that program?  Finally, how to accomodate 
> for such (how to fix)?
> 
> TIA

raw_input, nice.  Thanks!!
-- 
https://mail.python.org/mailman/listinfo/python-list

Python string replace the values

[Ganesh Pal]

In the fixed length string i.e "a",last 4 bits i.e "" should be
replaced by the user provided value ( the value is between 0001 + f f f f )
. I intend to form  final_string  using a fixed_string and an user provided
 user_string


Example:

fixed_string = "a"
user_string ='1'

final string = fixed_string  and  user_string

Example :

  "a" and "1" => a0001

  "a" and "aa" => c00aa


PS :  "and" this is not logical and it's just for example

If I concatenation using + or +=  or it's append the value at the end of
the string

>>> "a" + "1"===> expected was a0001
'a1'



 I am on python 2.7 and Linux ,  any ideas that you recommend  to handle
this


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

Re: Python string replace the values

[MRAB]

On 2017-09-01 18:13, Ganesh Pal wrote:

In the fixed length string i.e "a",last 4 bits i.e "" should be
replaced by the user provided value ( the value is between 0001 + f f f f )
. I intend to form  final_string  using a fixed_string and an user provided
  user_string


Example:

fixed_string = "a"
user_string ='1'

final string = fixed_string  and  user_string

Example :

   "a" and "1" => a0001

   "a" and "aa" => c00aa


PS :  "and" this is not logical and it's just for example

If I concatenation using + or +=  or it's append the value at the end of
the string


"a" + "1"===> expected was a0001

'a1'



  I am on python 2.7 and Linux ,  any ideas that you recommend  to handle
this


How long is user_string? len(user_string)
Truncate fixed_string by that many characters: fixed_string[ : 
-len(user_string)]


Then append the user_string: fixed_string[ : -len(user_string)] + 
user_string


Example:

>>> fixed_string = "a"
>>> user_string ='1'
>>> len(user_string)
1
>>> fixed_string[ : -len(user_string)]
'a000'
>>> fixed_string[ : -len(user_string)] + user_string
'a0001'

Note: this won't work properly if len(user_string) == 0, so if that 
could happen, just skip it. (Appending an empty string has no effect 
anyway!)

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

Re: Python string replace the values

[Rhodri James]

On 01/09/17 18:13, Ganesh Pal wrote:

"a" + "1"===> expected was a0001

'a1'


Why would you expect that?  Concatenation means "joining together", so

>>> "foo" + "bar"
'foobar'

No other mangling of either of your original strings is going to happen; 
there is no magic going on here.


What you want is most easily done using the zfill() string method to pad 
out the user's string with zeroes:


>>> fixed_string = "a"
>>> user_string = "1"
>>> final_string = fixed_string + user_string.zfill(4)
'a0001'

Note you should think VERY CAREFULLY about any user input like this. 
What are you going to do the user gives you too many digits, too few 
digits, non-digits?


--
Rhodri James *-* Kynesim Ltd
--
https://mail.python.org/mailman/listinfo/python-list

Re: Python string replace the values

[Irv Kalb]

> On Sep 1, 2017, at 10:13 AM, Ganesh Pal  wrote:
> 
> In the fixed length string i.e "a",last 4 bits i.e "" should be
> replaced by the user provided value ( the value is between 0001 + f f f f )
> . I intend to form  final_string  using a fixed_string and an user provided
> user_string
> 
> 
> Example:
> 
> fixed_string = "a"
> user_string ='1'
> 
> final string = fixed_string  and  user_string
> 
> Example :
> 
>  "a" and "1" => a0001
> 
>  "a" and "aa" => c00aa
> 
> 
> PS :  "and" this is not logical and it's just for example
> 
> If I concatenation using + or +=  or it's append the value at the end of
> the string
> 
 "a" + "1"===> expected was a0001
> 'a1'
> 
> 
> 
> I am on python 2.7 and Linux ,  any ideas that you recommend  to handle
> this
> 
> 
> Regards,
> Ganesh
> 

Here's a little function that should it it for you.  

(I assume that in your example "a" and "aa" => c00aa,  that really should 
have been   a00aa)

This should work for any size fixed_string and user_string (as long as the 
user_string is not longer than the fixed_string)

def mergeStrings(fixed_string, user_string):
nCharsInFixedString = len(fixed_string)
nCharsInUserString = len(user_string)

nCharsToGetFromFixedString = nCharsInFixedString - nCharsInUserString

finalString = fixed_string[:nCharsToGetFromFixedString] + user_string

return finalString

Irv

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

Re: Python string replace the values

[Ganesh Pal]

> (I assume that in your example "a" and "aa" => c00aa,  that really
should have been   a00aa)

Yes , thanks for noticing.

On Fri, Sep 1, 2017 at 11:18 PM, Irv Kalb  wrote:

>
> > On Sep 1, 2017, at 10:13 AM, Ganesh Pal  wrote:
> >
> > In the fixed length string i.e "a",last 4 bits i.e "" should be
> > replaced by the user provided value ( the value is between 0001 + f f f
> f )
> > . I intend to form  final_string  using a fixed_string and an user
> provided
> > user_string
> >
> >
> > Example:
> >
> > fixed_string = "a"
> > user_string ='1'
> >
> > final string = fixed_string  and  user_string
> >
> > Example :
> >
> >  "a" and "1" => a0001
> >
> >  "a" and "aa" => c00aa
> >
> >
> > PS :  "and" this is not logical and it's just for example
> >
> > If I concatenation using + or +=  or it's append the value at the end of
> > the string
> >
>  "a" + "1"===> expected was a0001
> > 'a1'
> >
> >
> >
> > I am on python 2.7 and Linux ,  any ideas that you recommend  to handle
> > this
> >
> >
> > Regards,
> > Ganesh
> >
>
> Here's a little function that should it it for you.
>
> (I assume that in your example "a" and "aa" => c00aa,  that really
> should have been   a00aa)
>
> This should work for any size fixed_string and user_string (as long as the
> user_string is not longer than the fixed_string)
>
> def mergeStrings(fixed_string, user_string):
> nCharsInFixedString = len(fixed_string)
> nCharsInUserString = len(user_string)
>
> nCharsToGetFromFixedString = nCharsInFixedString - nCharsInUserString
>
> finalString = fixed_string[:nCharsToGetFromFixedString] + user_string
>
> return finalString
>
> Irv
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python string replace the values

[Ganesh Pal]

>Note you should think VERY CAREFULLY about any user input like this. What
are you going to do the user gives you too many digits, too few digits,
non-digits

Thanks the solution i.e using zfill()  looks simple :) , we have a check
that will take care of user input than's for noticing that

On Fri, Sep 1, 2017 at 11:16 PM, Rhodri James  wrote:

> On 01/09/17 18:13, Ganesh Pal wrote:
>
>> "a" + "1"===> expected was a0001
>
 'a1'
>>
>
> Why would you expect that?  Concatenation means "joining together", so
>
> >>> "foo" + "bar"
> 'foobar'
>
> No other mangling of either of your original strings is going to happen;
> there is no magic going on here.
>
> What you want is most easily done using the zfill() string method to pad
> out the user's string with zeroes:
>
> >>> fixed_string = "a"
> >>> user_string = "1"
> >>> final_string = fixed_string + user_string.zfill(4)
> 'a0001'
>
> Note you should think VERY CAREFULLY about any user input like this. What
> are you going to do the user gives you too many digits, too few digits,
> non-digits?
>
> --
> Rhodri James *-* Kynesim Ltd
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

I am not able to run Python in Powershell

[The Cat Gamer]

fter I installed Python I try to open it in Powershell, by typing
python/python.exe.
It gives me an error:
python : The term 'python' is not recognized as the name of a cmdlet,
function, script file, or operable program. Check the spelling of the name,
or if a path was included, verify that the path is correct and try again.
At line:1 char:1
+ python
+ ~~
+ CategoryInfo  : ObjectNotFound: (python:String) [],
CommandNotFoundException
+ FullyQualifiedErrorId : CommandNotFoundException
This happens with version 3 and version 2. The newest versions and the
older versions none of them makes me able to open Python in Windows
Powershell. Are you guys aware of a fix?

(I already tried the environment fix and that didnt work as well)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: I am not able to run Python in Powershell

[MRAB]

On 2017-09-01 15:38, The Cat Gamer wrote:

fter I installed Python I try to open it in Powershell, by typing
python/python.exe.
It gives me an error:
python : The term 'python' is not recognized as the name of a cmdlet,
function, script file, or operable program. Check the spelling of the name,
or if a path was included, verify that the path is correct and try again.
At line:1 char:1
+ python
+ ~~
 + CategoryInfo  : ObjectNotFound: (python:String) [],
CommandNotFoundException
 + FullyQualifiedErrorId : CommandNotFoundException
This happens with version 3 and version 2. The newest versions and the
older versions none of them makes me able to open Python in Windows
Powershell. Are you guys aware of a fix?

(I already tried the environment fix and that didnt work as well)


"python" isn't on the path list, but the Python launcher "py" should be.

If you want to start Python 3.6 specifically (assuming it's installed):

py -3.6

If you want to start the default python:

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

Re: Solutions Manual Test Bank for McGraw-Hill's Taxation of Business Entities 2018 Edition 9th Edition by Spilker

[landytips90]

On Saturday, July 1, 2017 at 6:34:07 PM UTC-4, Test Banks wrote:
> Greetings, 
> 
> You can get Solution Manuals and Test Bank for " McGraw-Hill's Taxation of 
> Business Entities 2018 Edition 9th Edition by Brian Spilker and Benjamin 
> Ayers and John Barrick and Edmund Outslay and John Robinson and Connie Weaver 
> and Ronald Worsham " at very reasonable price. Our team is available 24/7 and 
> 365 days / year to respond your requests. Send us an email at 
> pro.fast(@)hotmail(dot)com 
> 
> Place your order at PRO.FAST(@)HOTMAIL(DOT)COM 
> 
> ISBN Numbers for this book (ISBN-10: 126000757X and ISBN-13: 9781260007572) 
> 
> MCGRAW-HILL'S TAXATION OF BUSINESS ENTITIES 2018 EDITION 9TH EDITION BY 
> SPILKER SOLUTIONS MANUAL TEST BANK 
> 
> You can also email for other Taxation books Solutions and Test Bank at low 
> prices and our team will try to get all resources you need. 
> 
> Do not post your reply here. Simply send us an email at PRO.FAST (AT) HOTMAIL 
> (DOT) COM 
> 
> Cheers,

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

virtualenv doesn't see my compiled tensorflow

[ross]

With the prebuilt version of tensorflow, I did:

   virtualenv --system-site-packages  ~/tensorflow

and somehow got it working with keras. Now I've compiled tensorflow in another 
shell/directory, where to start with I did:

   virtualenv --system-site-packages  .

and I got it running with keras on my net, with a nice speedup. Then I went 
back to my previous shell, did a deactivate, then

virtualenv --system-site-packages ~/tf_compile/tensorflow

to point to the dir that was '.' above, but my prompt path did not pick up 
'(tensorflow)' as before:

% virtualenv --system-site-packages ~/tf_compile/tensorflow
New python executable in /Users/priot/tf_compile/tensorflow/bin/python
Installing setuptools, pip, wheel...done.
priot keras%

and I get:

% python prog.py
  ...
  File "/Users/ppp/anaconda/lib/python2.7/site-
  packages/keras/backend/tensorflow_backend.py", line 1, in 
import tensorflow as tf
  ImportError: No module named tensorflow

Seems inconsistent.

% virtualenv --version
15.1.0

% python --version
Python 2.7.10 :: Anaconda custom (x86_64)

OS: OSx Darwin
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: virtualenv doesn't see my compiled tensorflow

[ross]

Solution: remember to run the 'activate' script:

% source ~/tf_compile/tensorflow/bin/activate


On Friday, September 1, 2017 at 2:39:33 PM UTC-7, ro...@cgl.ucsf.edu wrote:
> With the prebuilt version of tensorflow, I did:
> 
>virtualenv --system-site-packages  ~/tensorflow
> 
> and somehow got it working with keras. Now I've compiled tensorflow in 
> another shell/directory, where to start with I did:
> 
>virtualenv --system-site-packages  .
> 
> and I got it running with keras on my net, with a nice speedup. Then I went 
> back to my previous shell, did a deactivate, then
> 
> virtualenv --system-site-packages ~/tf_compile/tensorflow
> 
> to point to the dir that was '.' above, but my prompt path did not pick up 
> '(tensorflow)' as before:
> 
> % virtualenv --system-site-packages ~/tf_compile/tensorflow
> New python executable in /Users/priot/tf_compile/tensorflow/bin/python
> Installing setuptools, pip, wheel...done.
> priot keras%
> 
> and I get:
> 
> % python prog.py
>   ...
>   File "/Users/ppp/anaconda/lib/python2.7/site-
>   packages/keras/backend/tensorflow_backend.py", line 1, in 
> import tensorflow as tf
>   ImportError: No module named tensorflow
> 
> Seems inconsistent.
> 
> % virtualenv --version
> 15.1.0
> 
> % python --version
> Python 2.7.10 :: Anaconda custom (x86_64)
> 
> OS: OSx Darwin

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

Re: If you are running 32-bit 3.6 on Windows, please test this

[eryk sun]

On Fri, Sep 1, 2017 at 3:23 AM, Peter Otten <__pete...@web.de> wrote:
>
> I think you have to specify the types yourself:
>
 import ctypes
 libm = ctypes.cdll.LoadLibrary("libm.so")
 libm.sqrt(42)
> 0
 libm.sqrt.argtypes = [ctypes.c_double]
 libm.sqrt.restype = ctypes.c_double
 libm.sqrt(42)
> 6.48074069840786

On POSIX systems, use ctypes.util.find_library('m'), which, for
example, resolves to "libm.so.6" in Ubuntu Linux 16.04. On the same
system, "libm.so" is an ld script that's used by the compile-time
linker.

$ cat /usr/lib/x86_64-linux-gnu/libm.so
/* GNU ld script
*/
OUTPUT_FORMAT(elf64-x86-64)
GROUP ( /lib/x86_64-linux-gnu/libm.so.6
AS_NEEDED (
/usr/lib/x86_64-linux-gnu/libmvec_nonshared.a
/lib/x86_64-linux-gnu/libmvec.so.1 ) )

The runtime linker doesn't know how to handle this script.

>>> ctypes.CDLL('libm.so')
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3.5/ctypes/__init__.py",
line 347, in __init__
self._handle = _dlopen(self._name, mode)
OSError: /usr/lib/x86_64-linux-gnu/libm.so: invalid ELF header

On Windows, Python 3.5+ uses the Universal C Runtime. You can
reference it directly as follows:

ucrt = ctypes.CDLL('ucrtbase', use_errno=True)

But in practice you should use the math API set [1]. For example:

>>> crt_math = ctypes.CDLL('api-ms-win-crt-math-l1-1-0',
... use_errno=True)
>>> crt_math.sqrt.restype = ctypes.c_double
>>> crt_math.sqrt.argtypes = [ctypes.c_double]
>>> crt_math.sqrt(1.3)
1.140175425099138
>>> ctypes.get_errno()
0

Note that find_library('c') and find_library('m') both return None
under Windows in Python 3.5+.

>>> ctypes.util.find_library('c') is None
True
>>> ctypes.util.find_library('m') is None
True

[1]: 
https://msdn.microsoft.com/en-us/library/mt656782#_api-ms-win-crt-math-l1-1-0
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: If you are running 32-bit 3.6 on Windows, please test this

[eryk sun]

On Fri, Sep 1, 2017 at 2:24 AM, Pavol Lisy  wrote:
>
> I was trying to call sqrt using ctypes from msvcrt but I am not succesful:
>
> import ctypes
> msc = ctypes.windll.msvcrt

msvcrt.dll is private to Windows components. It's not intended for
applications. See my previous post in this thread for the correct
shared library to load for Python 3.5+.

Also, WinDLL (or windll) is for stdcall, whereas CRT functions use
cdecl (CDLL or cdll). In 64-bit it isn't a problem since cdecl and
stdcall are the same in x64, but this will fail in 32-bit x86.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Case-insensitive string equality

[Steve D'Aprano]

On Sat, 2 Sep 2017 01:41 am, Chris Angelico wrote:

> On Fri, Sep 1, 2017 at 11:22 PM, Steve D'Aprano
>  wrote:
>> On Fri, 1 Sep 2017 09:53 am, MRAB wrote:
>>
>>> What would you expect the result would be for:
>>>
>>>  "\N{LATIN SMALL LIGATURE FI}".case_insensitive_find("F")
>>>
>>>  "\N{LATIN SMALL LIGATURE FI}".case_insensitive_find("I)
>>
>> That's easy.
>>
>> -1 in both cases, since neither "F" nor "I" is found in either string. We can
>> prove this by manually checking:
>>
>> py> for c in "\N{LATIN SMALL LIGATURE FI}":
>> ... print(c, 'F' in c, 'f' in c)
>> ... print(c, 'I' in c, 'i' in c)
>> ...
>> fi False False
>> fi False False
>>
>>
>> If you want some other result, then you're not talking about case
>> sensitivity.
> 
 "\N{LATIN SMALL LIGATURE FI}".upper()
> 'FI'


The question wasn't what "\N{LATIN SMALL LIGATURE FI}".upper() would find,
but "\N{LATIN SMALL LIGATURE FI}".

Nor did they ask about

"\N{LATIN SMALL LIGATURE FI}".replace("\N{LATIN SMALL LIGATURE
FI}", "Surprise!")



> So what's the definition of "case insensitive find"? The most simple
> and obvious form is:
> 
> def case_insensitive_find(self, other):
> return self.casefold().find(other.casefold())

That's not the definition, that's an implementation.


-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

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

Re: Python string replace the values

[Steve D'Aprano]

On Sat, 2 Sep 2017 03:13 am, Ganesh Pal wrote:

> Example :
> 
>   "a" and "1" => a0001
> 
>   "a" and "aa" => c00aa

Why does the leading 'a' change to a 'c'? Is that a mistake? I'll assume its a
typo.

You want string slicing.

base = 'a'
extra = 'ab'
print( base[:-len(extra)] + extra )



-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

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

Re: Case-insensitive string equality

[Chris Angelico]

On Sat, Sep 2, 2017 at 10:09 AM, Steve D'Aprano
 wrote:
> The question wasn't what "\N{LATIN SMALL LIGATURE FI}".upper() would find,
> but "\N{LATIN SMALL LIGATURE FI}".
>
> Nor did they ask about
>
> "\N{LATIN SMALL LIGATURE FI}".replace("\N{LATIN SMALL LIGATURE
> FI}", "Surprise!")
>
>> So what's the definition of "case insensitive find"? The most simple
>> and obvious form is:
>>
>> def case_insensitive_find(self, other):
>> return self.casefold().find(other.casefold())
>
> That's not the definition, that's an implementation.

It's a reference implementation that defines certain semantics.
Obviously you can *actually* implement it using some kind of C-level
loop or something, as long as you can define the semantics somehow.

So what IS your definition of "case insensitive find"? Do you
case-fold both strings or just one? What do you do about
length-changing case folding?

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

Re: Case-insensitive string equality

[Steve D'Aprano]

On Sat, 2 Sep 2017 01:41 am, Chris Angelico wrote:

> Aside from lower(), which returns the string unchanged, the case
> conversion rules say that this contains two letters.

Do you have a reference to that?

I mean, where in the Unicode case conversion rules is that stated? You cannot
take the behaviour of Python as necessarily correct here -- it may be that the
behaviour of Python is erroneous.


For what its worth, even under Unicode's own rules, there are always going to be
odd corner cases that surprise people. The most obvious cases are:


- dotted and dottless i

- the German eszett, ß, which has two official[1] uppercase forms: 'SS' and an
uppercase eszett

- long s, ſ, which may or may not be treated as distinct from s

- likewise for ligatures -- is æ a ligature, or is it Old English ash?


You can't keep everybody happy. Doesn't mean we can't meet 99% of the usescases.

After all, what do you think the regex case insensitive matching does?




[1] I believe that the German government has now officially recognised the
uppercase form of ß.



-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

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

Re: Case-insensitive string equality

[Chris Angelico]

On Sat, Sep 2, 2017 at 10:31 AM, Steve D'Aprano
 wrote:
> On Sat, 2 Sep 2017 01:41 am, Chris Angelico wrote:
>
>> Aside from lower(), which returns the string unchanged, the case
>> conversion rules say that this contains two letters.
>
> Do you have a reference to that?
>
> I mean, where in the Unicode case conversion rules is that stated? You cannot
> take the behaviour of Python as necessarily correct here -- it may be that the
> behaviour of Python is erroneous.

Yep! It's all in here.

ftp://ftp.unicode.org/Public/UCD/latest/ucd/SpecialCasing.txt

> For what its worth, even under Unicode's own rules, there are always going to 
> be
> odd corner cases that surprise people. The most obvious cases are:
>
> You can't keep everybody happy. Doesn't mean we can't meet 99% of the 
> usescases.
>
> After all, what do you think the regex case insensitive matching does?

Honestly, I don't know what it does without checking. But code is
often *wrong* due to backward compatibility concerns. Then you have to
decide whether, for a brand new API, it's better to "do the same as
the regex module" or to "do what the Unicode consortium says".

As it turns out, the Python 're' module doesn't match the letters
against the ligature:

>>> re.search("F", "\N{LATIN SMALL LIGATURE FI}", re.IGNORECASE)
>>> re.search("f", "\N{LATIN SMALL LIGATURE FI}", re.IGNORECASE)
>>> re.search("I", "\N{LATIN SMALL LIGATURE FI}", re.IGNORECASE)
>>> re.search("i", "\N{LATIN SMALL LIGATURE FI}", re.IGNORECASE)
>>> re.search("S", "\N{LATIN SMALL LETTER SHARP S}", re.IGNORECASE)
>>> re.search("s", "\N{LATIN SMALL LETTER SHARP S}", re.IGNORECASE)
>>>

I would consider that code to be incorrect.

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

Re: Case-insensitive string equality

[Steve D'Aprano]

On Fri, 1 Sep 2017 01:29 am, Tim Chase wrote:

> On 2017-08-31 07:10, Steven D'Aprano wrote:
>> So I'd like to propose some additions to 3.7 or 3.8.
> 
> Adding my "yes, a case-insensitive equality-check would be useful"
> with the following concerns:
> 
> I'd want to have an optional parameter to take locale into
> consideration.  E.g.

Does regular case-sensitive equality take the locale into consideration?

How do I convince Python to return true for these?

'i'.upper() == 'İ'
'I'.lower() == 'ı'


I'm 99% sure that these are rhetorical questions where the answers are
obviously:

- No it doesn't.
- And you can't.

If regular case-sensitive string comparisons don't support the locale, why
should case-insensitive comparisons be required to?

We should not confuse "nice to have" for "must have". As far as I'm concerned,
the only "must have" is that ASCII letters do the right thing. Everything
beyond that is a "quality of implementation" issue.


In any case, thanks to everyone for their feedback. Clearly there not enough
support for this for me to even bother taking it to Python-Ideas.




-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

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

Re: Case-insensitive string equality

[Chris Angelico]

On Sat, Sep 2, 2017 at 12:21 PM, Steve D'Aprano
 wrote:
> On Fri, 1 Sep 2017 01:29 am, Tim Chase wrote:
>
>> On 2017-08-31 07:10, Steven D'Aprano wrote:
>>> So I'd like to propose some additions to 3.7 or 3.8.
>>
>> Adding my "yes, a case-insensitive equality-check would be useful"
>> with the following concerns:
>>
>> I'd want to have an optional parameter to take locale into
>> consideration.  E.g.
>
> Does regular case-sensitive equality take the locale into consideration?
>
> How do I convince Python to return true for these?
>
> 'i'.upper() == 'İ'
> 'I'.lower() == 'ı'
>
>
> I'm 99% sure that these are rhetorical questions where the answers are
> obviously:
>
> - No it doesn't.
> - And you can't.
>
> If regular case-sensitive string comparisons don't support the locale, why
> should case-insensitive comparisons be required to?
>
> We should not confuse "nice to have" for "must have". As far as I'm concerned,
> the only "must have" is that ASCII letters do the right thing. Everything
> beyond that is a "quality of implementation" issue.

The only "must have" is that the locale-independent conversions do the
right thing. We already have str.casefold() that correctly handles
>99% of situations; the easiest way to craft something like this is to
define it in terms of that.

> In any case, thanks to everyone for their feedback. Clearly there not enough
> support for this for me to even bother taking it to Python-Ideas.

Agreed; if this were important enough for someone to want to run the
gauntlet of -ideas and -dev, I'd predict that it would be one of those
VERY hotly debated topics.

ChrisA

On Sat, Sep 2, 2017 at 12:21 PM, Steve D'Aprano
 wrote:
> On Fri, 1 Sep 2017 01:29 am, Tim Chase wrote:
>
>> On 2017-08-31 07:10, Steven D'Aprano wrote:
>>> So I'd like to propose some additions to 3.7 or 3.8.
>>
>> Adding my "yes, a case-insensitive equality-check would be useful"
>> with the following concerns:
>>
>> I'd want to have an optional parameter to take locale into
>> consideration.  E.g.
>
> Does regular case-sensitive equality take the locale into consideration?
>
> How do I convince Python to return true for these?
>
> 'i'.upper() == 'İ'
> 'I'.lower() == 'ı'
>
>
> I'm 99% sure that these are rhetorical questions where the answers are
> obviously:
>
> - No it doesn't.
> - And you can't.
>
> If regular case-sensitive string comparisons don't support the locale, why
> should case-insensitive comparisons be required to?
>
> We should not confuse "nice to have" for "must have". As far as I'm concerned,
> the only "must have" is that ASCII letters do the right thing. Everything
> beyond that is a "quality of implementation" issue.
>
>
> In any case, thanks to everyone for their feedback. Clearly there not enough
> support for this for me to even bother taking it to Python-Ideas.
>
>
>
>
> --
> Steve
> “Cheer up,” they said, “things could be worse.” So I cheered up, and sure
> enough, things got worse.
>
> --
> https://mail.python.org/mailman/listinfo/python-list
-- 
https://mail.python.org/mailman/listinfo/python-list