Re: msvcr100.dll missing ... error started after Windows 10 update to 10586.17
Am 05.12.15 um 00:26 schrieb Glenn Linderman: My wife's 64-bit Win8 home machine has 32-bit Python 3.3 installed. Then it upgraded to Win 8.1. Then I upgraded it to Win 10. Then I upgraded it to Threshold 2. It gets regular automatic updates also, like the one last night to build 10586.17. That's the history. When she tried a python script today, it failed, with an error saying that MSVCR100.dll was missing. After a few false starts, like being surprised that the error happened when it worked yesterday, and that there was an MSVCR100.dll in %windir%\system32, doing a search for all MSVCR100.dll on her machine discovered quite a few in various application directories, but then also one in \windows.old\WINDOWS\SysWOW64, the light-bulb blinked on, I copied that one to the \python33 directory, and everything works. These MSVCR*DLL are a bit different from other DLLs. They constitute the runtime for programs compiled using Visual Studio 2010. Instead of mucking around with these files manually, you should install the "Redustributable Package" found here https://www.microsoft.com/en-us/download/details.aspx?id=14632 for 32bit or here https://www.microsoft.com/en-us/download/details.aspx?id= for 64 bit. Both can be installed simultaneously to support 32bit and 64bit programs. There is also a "Visual Studio 2010 SP1" version - I'm not sure which one is correct. It depends on the version of the compiler that Python was built with. Why M$ chose to delete MSVCR100.dll from %windir%\SysWOW64 in the recent update is a mystery, however. Maybe the upgrade process didn't recognize it as part of the rediistributable, maybe it was not installed correctly. The MS recommended way for an installer is to package that "redistributable" and to launch it during the installation of the main program. So this is just a data point and warning and solution, not really an expectation that anyone will be able to explain M$. Glenn -- https://mail.python.org/mailman/listinfo/python-list
Re: Unicode failure
On 5 Dec 2015 06:10, "D'Arcy J.M. Cain" wrote: > > On Fri, 4 Dec 2015 18:28:22 -0500 > Terry Reedy wrote: > > On 12/4/2015 1:07 PM, D'Arcy J.M. Cain wrote: > > > I thought that going to Python 3.4 would solve my Unicode issues > > > > Within Python itself, that should be mostly true. As soon as you > > send text to a display, the rules of the display device take over. > > OK but my display (xterm) can display those characters. I see it when > I dump unicode text from my database. > > > > #! /usr/bin/python3 > > > # -*- coding: UTF-8 -*- > > > > Redundant, as this is the default for 3.x > > I assumed so but belt and suspenders, right? > > > Tk widgets, and hence IDLE windows, will print any character from > > \u to \u without raising, even if the result is blank or �. > > Higher codepoints fail, but allowing the entire BMP is better than > > any Windows codepage. > > Not sure I follow all this but to be clear, I am not using Tk, Idle or > Windows. I guess I should have mentioned that I am on Unix but I > thought that the hash-bang would have given that away. To be complete, > I am running xterms on Xubuntu connected to NetBSD 7.0. The data is > coming from a PostgreSQL 9.3.5 database. I am using a beta of PyGreSQL > 5.0 (I am the lead developer for it) and I checked and the type > returned is str, not bytes. The database encoding is UTF8. Yeah but the error you showed was from print trying to encode the string as ASCII. For some reason Python thinks that stdout is ASCII I think. So I repeat: what is SYS.stdout.encoding? If you're using xterm I think it will be derived from LANG. So what's LANG? -- Oscar -- https://mail.python.org/mailman/listinfo/python-list
Python 3.4 + pyUSB 1.0 + libusb-win32 1.2.6.0, what happens?
I am new to python. I had a USB HID device which behavior is that the host send
a 64 bytes commands to it, after complete the execution of this commands it
send back a 64 bytes status to the host, so the host can check the status and
decide the next step.
When I run it under Win7 with SwiftForth 3.5.9 (a Forth system) and
libusb-win32 1.2.6.0, it performs well. But when I test it under the same PC
with python 3.4, pyUSB 1.0 and libusb-win32 1.2.6.0, it performs a little
strange. The status read back always fail at the first time (return zero
length) and success at the second time.
>>> dev.write(0x02, cmdBuf)
64
>>> dev.read(0x81, 64, 5000)
array('B')# no data returned
>>> dev.read(0x81, 64, 5000)
array('B', [165, 0, ])# this one is correct, totally 64 bytes
another "strange" thing is that I had a 5000 timeout in the read but I see no
delay at the first read. It returns immediately. I suppose it should wait for 5
seconds long before it returns. Right?
Any hint?
Best Regards,
Jach Fong
--
https://mail.python.org/mailman/listinfo/python-list
increment/decrement operators
Hi, I'm a relative newbie to python, and this NG, but it's certainly growing on me. One thing I'm missing is the increment/decrement operator from C, ie x++, and its ilk. Likewise x += y. is there any way of doing this in Python? TIA, Tony -- https://mail.python.org/mailman/listinfo/python-list
Re: increment/decrement operators
Am 05.12.2015 um 13:40 schrieb Tony van der Hoff: Hi, I'm a relative newbie to python, and this NG, but it's certainly growing on me. One thing I'm missing is the increment/decrement operator from C, ie x++, and its ilk. Likewise x += y. is there any way of doing this in Python? Quick answer: x += y works. (Well, it should.) x++ doesn't. Long answer: I'm sure someone more experienced will come up with one shortly. :-) Until then I found this: http://stackoverflow.com/a/1485854 -- Robin Koch -- https://mail.python.org/mailman/listinfo/python-list
Re: Unicode failure
On Sat, Dec 5, 2015 at 12:10 AM, Chris Angelico wrote: > On Sat, Dec 5, 2015 at 5:06 PM, Terry Reedy wrote: >> On 12/4/2015 10:22 PM, Random832 wrote: >>> >>> On 2015-12-04, Terry Reedy wrote: Tk widgets, and hence IDLE windows, will print any character from \u to \u without raising, even if the result is blank or �. Higher codepoints fail, but allowing the entire BMP is better than any Windows codepage. >>> >>> >>> Well, any bar 1200, 1201, 12000, 12001, 65000, 65001, and 54936. >> >> >> Test before you post. >> > for cp in 1200, 1201, 12000, 12001, 65000, 65001, 54936: >> print(chr(cp)) >> >> >> Ұ >> ұ >> ⻠ >> ⻡ >> � >> � >> 횘 > > Those numbers aren't codepoints, they're code pages. Specifically, > they're UTF-16, UTF-32, UTF-8, and I'm not sure what 54936 is. Codepage 65000 is UTF-7. Codepage 54936 [1] is GB18030, the official character set of China. It's a UTF superset of GBK. For comparison, codepage 936 is a subset of GBK (it's missing 95 characters) plus the Euro symbol. [1]: https://msdn.microsoft.com/en-us/library/dd317756 -- https://mail.python.org/mailman/listinfo/python-list
Re: increment/decrement operators
On 05/12/15 12:56, Robin Koch wrote: Am 05.12.2015 um 13:40 schrieb Tony van der Hoff: Hi, I'm a relative newbie to python, and this NG, but it's certainly growing on me. One thing I'm missing is the increment/decrement operator from C, ie x++, and its ilk. Likewise x += y. is there any way of doing this in Python? Quick answer: x += y works. (Well, it should.) x++ doesn't. Long answer: I'm sure someone more experienced will come up with one shortly. :-) Until then I found this: http://stackoverflow.com/a/1485854 Thanks for the link -- https://mail.python.org/mailman/listinfo/python-list
Re: increment/decrement operators
On Sat, 5 Dec 2015 13:56:47 +0100 Robin Koch wrote: > x += y works. (Well, it should.) It does, even on objects other than numbers. >>> x = "abc" >>> y = "def" >>> x += y >>> x 'abcdef' > x++ doesn't. No but it's just a special case of the above. >>> x = 1 >>> x += 1 >>> x 2 -- D'Arcy J.M. Cain Vybe Networks Inc. http://www.VybeNetworks.com/ IM:da...@vex.net VoIP: sip:da...@vybenetworks.com -- https://mail.python.org/mailman/listinfo/python-list
Re: increment/decrement operators
On 12/5/2015 9:41 AM, D'Arcy J.M. Cain wrote: On Sat, 5 Dec 2015 13:56:47 +0100 Robin Koch wrote: x += y works. (Well, it should.) It does, even on objects other than numbers. x = "abc" y = "def" x += y x 'abcdef' x++ doesn't. No but it's just a special case of the above. x = 1 x += 1 x 2 Apple is removing the ++ and -- pre- and post- increment and decrement operators from Swift 3.0 as redundant with += 1. https://github.com/apple/swift-evolution/blob/master/proposals/0004-remove-pre-post-inc-decrement.md The following section is a good summary of why they were never added to Python, and should not be. ''' Disadvantages of These Operators 1. These operators increase the burden to learn Swift as a first programming language - or any other case where you don't already know these operators from a different language. 2. Their expressive advantage is minimal - x++ is not much shorter than x += 1. 3. Swift already deviates from C in that the =, += and other assignment-like operations returns Void (for a number of reasons). These operators are inconsistent with that model. 4. Swift has powerful features that eliminate many of the common reasons you'd use ++i in a C-style for loop in other languages, so these are relatively infrequently used in well-written Swift code. These features include the for-in loop, ranges, enumerate, map, etc. 5. Code that actually uses the result value of these operators is often confusing and subtle to a reader/maintainer of code. They encourage "overly tricky" code which may be cute, but difficult to understand. 6. While Swift has well defined order of evaluation, any code that depended on it (like foo(++a, a++)) would be undesirable even if it was well-defined. 7. These operators are applicable to relatively few types: integer and floating point scalars, and iterator-like concepts. They do not apply to complex numbers, matrices, etc. 8. Having to support these could add complexity to the potential revised numerics model. Finally, these fail the metric of "if we didn't already have these, would we add them to Swift 3?" ''' -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: increment/decrement operators
On 05/12/2015 15:43, Terry Reedy wrote: On 12/5/2015 9:41 AM, D'Arcy J.M. Cain wrote: On Sat, 5 Dec 2015 13:56:47 +0100 Robin Koch wrote: x += y works. (Well, it should.) It does, even on objects other than numbers. x = "abc" y = "def" x += y x 'abcdef' x++ doesn't. No but it's just a special case of the above. x = 1 x += 1 x 2 Apple is removing the ++ and -- pre- and post- increment and decrement operators from Swift 3.0 as redundant with += 1. https://github.com/apple/swift-evolution/blob/master/proposals/0004-remove-pre-post-inc-decrement.md The following section is a good summary of why they were never added to Python, and should not be. ''' Disadvantages of These Operators 1. These operators increase the burden to learn Swift as a first programming language - or any other case where you don't already know these operators from a different language. 2. Their expressive advantage is minimal - x++ is not much shorter than x += 1. The latter is not the same. Some of the differences are: * ++ and -- are often inside inside expressions and return values (unlike x+=1 in Python) * x++ and x-- return the /current/ value of x, unlike x+=1 even if it were to return a value; it would be the new value * x+=1 requires you to hard-code the value 1, but ++ is not necessarily stepping by 1. You can imagine ++ stepping something to its next value. However, if ++ and -- are only used as statements, then why not simply map them to x+=1? In Python, that would need to be x++ and x-- as ++x or --x have existing meanings. -- Bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: Unicode failure (Solved)
On Fri, 4 Dec 2015 18:28:22 -0500 Terry Reedy wrote: > Tk widgets, and hence IDLE windows, will print any character from > \u to \u without raising, even if the result is blank or �. > Higher codepoints fail, but allowing the entire BMP is better than > any Windows codepage. Thanks to all. Following up on the various posts brought me to information that solved my problem. Basicall I added "export PYTHONIOENCODING=utf8" to my environment and "SetEnv PYTHONIOENCODING utf8" in my Apache config and now things are working as they should. Thanks all. -- D'Arcy J.M. Cain Vybe Networks Inc. http://www.VybeNetworks.com/ IM:da...@vex.net VoIP: sip:da...@vybenetworks.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Question about split method
On Wed, 2 Dec 2015 14:44:30 -0600, Ian Kelly wrote:
> On Wed, Dec 2, 2015 at 2:37 PM, Robert wrote:
[snip]
>> ss0="1, 2, 4, 8, 16".split(", ")
[snip]
> Try help(str.split)
Or if, like me, you can't remember the magic word "str", ask:
help("".split)
and you know you're asking about the right "split".
--
To email me, substitute nowhere->runbox, invalid->com.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Unicode failure
On 2015-12-05, Terry Reedy wrote: > On 12/4/2015 10:22 PM, Random832 wrote: >> Well, any bar 1200, 1201, 12000, 12001, 65000, 65001, and 54936. > > Test before you post. As someone else pointed out, I meant that as a list of codepages which support all Unicode codepoints, not a list of codepoints not supported by Tk's UCS-2. Sorry, I assumed everyone knew offhand that 65001 was UTF-8 and would infer that the rest were for other UTF encodings. -- https://mail.python.org/mailman/listinfo/python-list
Re: filter a list of strings
On Thu, 3 Dec 2015 10:27:19 +0100, wrote: [snip] > I often saw constructions like this > x for x in y if ... > But I don't understand that combination of the Python keywords (for, > in, if) I allready know. It is to complex to imagine what there really > happen. Don't give up! List comprehensions are one of the coolest things in Python. Maybe this simple example will make it click for you: >>> [x**2 for x in [1,2,3,4] if x != 2] [1, 9, 16] -- To email me, substitute nowhere->runbox, invalid->com. -- https://mail.python.org/mailman/listinfo/python-list
Re: Question about split method
On Saturday, December 5, 2015 at 2:29:28 PM UTC-5, Peter Pearson wrote:
> On Wed, 2 Dec 2015 14:44:30 -0600, Ian Kelly wrote:
> > On Wed, Dec 2, 2015 at 2:37 PM, Robert wrote:
> [snip]
> >> ss0="1, 2, 4, 8, 16".split(", ")
> [snip]
> > Try help(str.split)
>
> Or if, like me, you can't remember the magic word "str", ask:
>
> help("".split)
>
> and you know you're asking about the right "split".
>
> --
> To email me, substitute nowhere->runbox, invalid->com.
Thanks for your smart method.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Question about split method
On 05/12/2015 19:51, Robert wrote:
On Saturday, December 5, 2015 at 2:29:28 PM UTC-5, Peter Pearson wrote:
On Wed, 2 Dec 2015 14:44:30 -0600, Ian Kelly wrote:
On Wed, Dec 2, 2015 at 2:37 PM, Robert wrote:
[snip]
ss0="1, 2, 4, 8, 16".split(", ")
[snip]
Try help(str.split)
Or if, like me, you can't remember the magic word "str", ask:
help("".split)
and you know you're asking about the right "split".
--
To email me, substitute nowhere->runbox, invalid->com.
Thanks for your smart method.
The even smarter method is:
help(''.split)
as this saves you reaching for the shift key :)
--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.
Mark Lawrence
--
https://mail.python.org/mailman/listinfo/python-list
Re: Unicode failure
On 12/5/2015 2:44 PM, Random832 wrote: On 2015-12-05, Terry Reedy wrote: On 12/4/2015 10:22 PM, Random832 wrote: Well, any bar 1200, 1201, 12000, 12001, 65000, 65001, and 54936. Test before you post. As someone else pointed out, I meant that as a list of codepages which support all Unicode codepoints, not a list of codepoints not supported by Tk's UCS-2. Sorry, I assumed everyone knew offhand that 65001 was UTF-8 So Microsoft claims, but it is not terribly useful. Currently, on my Win 10 system, 'chcp 65001' results in sys.stdout.encoding = 'cp65001', and for cp in 1200, 1201, 12000, 12001, 65000, 65001, 54936: print(chr(cp)) running without the usual exception. But of the above numbers mis-interpreted as codepoints, only 1200 and 1201 print anything other than a box with ?, whereas IDLE printed 3 other chars for 3 other assigned codepoints. If I change the console font to Lucida Console, which I use in IDLE, even chr(1200) gives a box. and would infer that the rest were for other UTF encodings. After re-reading, I see how I might have inferred that. Anyway, the OP found the solution for his system. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
[RELEASED] Python 2.7.11
Python 2.7.11, the latest bugfix release of the Python 2.7 series, is now available for download at https://www.python.org/downloads/release/python-2711/ Thank you as always to Steve Dower and Ned Deily, who build our binaries. Enjoy the rest of the year, Benjamin -- https://mail.python.org/mailman/listinfo/python-list
Re: Question about split method
On 05/12/15 20:27, Mark Lawrence wrote:
On 05/12/2015 19:51, Robert wrote:
On Saturday, December 5, 2015 at 2:29:28 PM UTC-5, Peter Pearson wrote:
On Wed, 2 Dec 2015 14:44:30 -0600, Ian Kelly
wrote:
On Wed, Dec 2, 2015 at 2:37 PM, Robert wrote:
[snip]
ss0="1, 2, 4, 8, 16".split(", ")
[snip]
Try help(str.split)
Or if, like me, you can't remember the magic word "str", ask:
help("".split)
and you know you're asking about the right "split".
--
To email me, substitute nowhere->runbox, invalid->com.
Thanks for your smart method.
The even smarter method is:
help(''.split)
as this saves you reaching for the shift key :)
... except you're already pressing it for the open parenthesis ... ;)
E.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Unicode failure
On Sat, Dec 5, 2015 at 4:03 PM, Terry Reedy wrote: > On 12/5/2015 2:44 PM, Random832 wrote: >> As someone else pointed out, I meant that as a list of codepages >> which support all Unicode codepoints, not a list of codepoints >> not supported by Tk's UCS-2. Sorry, I assumed everyone knew >> offhand that 65001 was UTF-8 > > So Microsoft claims, but it is not terribly useful. Using codepage 65001 is how one encodes/decodes UTF-8 using the Windows API, i.e. WideCharToMultiByte and MultiByteToWideChar. If you're just referring to the console, then I agree for the most part. The console, even in Windows 10, still has two major flaws when using UTF-8. The biggest problem is that non-ASCII input gets read as EOF (i.e. 0 bytes read) because of a bug in how conhost.exe (the process that hosts the console) converts its internal input buffer. Instead of dynamically determining how many characters to encode based on the current codepage, it assumes an N byte user buffer is a request for N characters, which obviously fails with non-ASCII UTF-8. What's worse is that it doesn't fail the call. It returns to the client that it successfully read 0 bytes.This causes Python's REPL to quit and input() to raise EOFError. The 2nd problem that still exists in Windows 10 is that the console doesn't save state across writes, so a 2-4 byte UTF-8 code sequence that gets split into 2 writes due to buffering gets displayed in the console as 2-4 replacement characters (i.e. U+FFFD). Most POSIX terminals don't suffer from this problem because they natively use 8-bit strings, whereas Windows transcodes to UTF-16. Prior to Windows 8, there's another annoying bug. WriteFile and WriteConsoleA return the number of wchar_t elements written instead of the number of bytes written. So a buffered writer will write successively smaller slices of the output buffer until the two numbers agree. You end up with a (potentially long) trail of garbage at the end of every write that contains non-ASCII characters. Since Windows doesn't allow UTF-8 as the system codepage (i.e. the [A]NSI API), it's probably only by accident that UTF-8 works in the console at all. Unicode works best (though not perfectly) via the console's wide-character API. The win-unicode-console package provides this functionality for Python 2 and 3. > Currently, on my Win 10 system, 'chcp 65001' results in > sys.stdout.encoding = 'cp65001', and > > for cp in 1200, 1201, 12000, 12001, 65000, 65001, 54936: > print(chr(cp)) > running without the usual exception. But of the above numbers > mis-interpreted as codepoints, only 1200 and 1201 print anything other than > a box with ?, whereas IDLE printed 3 other chars for 3 other assigned > codepoints. If I change the console font to Lucida Console, which I use in > IDLE, even chr(1200) gives a box. 65000 and 65001 aren't characters. Code points 12000, 12001 and 54936 are East-Asian characters: >>> from unicodedata import name, east_asian_width >>> for n in (12000, 12001, 54936): ... c = chr(n) ... print(n, east_asian_width(c), name(c)) ... 12000 W CJK RADICAL C-SIMPLIFIED EAT 12001 W CJK RADICAL HEAD 54936 W HANGUL SYLLABLE HOELS The console window can't mix narrow glyphs with wide glyphs. Its font rendering still has mostly the same limitations that it had when it debuted in Windows NT 3.1 (1993). To display wide CJK glyphs in the console, set the system locale to an East-Asian region and restart Windows (what a piece of... cake). The console also stores only one 16-bit wchar_t code per character cell, so a UTF-16 surrogate pair representing a non-BMP character (e.g. one of the popular emoji characters) displays as two rectangle glyphs. However, at least the code values are preserved when copied from the console to a window that displays UTF-16 text properly. Alternatively, use ConEmu [1] to hide the original console and display its contents in a window that handles text more flexibly. It also hacks the console API via DLL injection to work around bugs and provide Xterm emulation. [1]: http://conemu.github.io -- https://mail.python.org/mailman/listinfo/python-list
