From waaaseee at gmail.com Sat Dec 12 19:38:53 2015 From: waaaseee at gmail.com (Wasi Khan) Date: Sun, 13 Dec 2015 05:38:53 +0500 Subject: [python-win32] pywintypes.com_error: -2147417843. Word COM related issue. Message-ID: Hello everyone, I need to get some text from a document when I press a certain key (captured via PyHook). I get the following error when I try to run word.ActiveDocument.ActiveWindow.Selection.Text *pywintypes.com_error: (-2147417843, 'An outgoing call cannot be made since the application is dispatching an input-synchronous call.', None, None)* Putting a sleep before the call mitigates this issues, but Windows starts to ignore PyHook calls after like 10 hits which is sub par. It is hard for me to understand which calls is ingoing/outgoing. What's the best way to avoid this error? Any help would be appreciated. Wasi -------------- next part -------------- An HTML attachment was scrubbed... URL: From framstag at rus.uni-stuttgart.de Tue Dec 15 03:19:15 2015 From: framstag at rus.uni-stuttgart.de (Ulli Horlacher) Date: Tue, 15 Dec 2015 09:19:15 +0100 Subject: [python-win32] drag&drop files with non-ASCII filenames? Message-ID: <20151215081915.GB29648@rus.uni-stuttgart.de> I have a python 2.7 program which runs in a console window and upload files. To specify the files, the user uses Windows drag&drop (via explorer) or copy&paste. To read it I use: file = get_paste() def get_paste(): import msvcrt while True: c = msvcrt.getch() if c == '\t': return '' if c == '\003' or c == '\004': return None if not (c == '\n' or c == '\r'): break paste = c while msvcrt.kbhit(): c = msvcrt.getch() if c == '\n' or c == '\r': break paste += c if match(r'\s',paste): paste = subst('^"(.+)"$',r'\1',paste) return paste The problem is that get_paste() contains only ASCII. All non-ASCII characters of the file name are lost. Is there an other methode of reading the input, with ALL characters, without manually hitting [ENTER]? -- Ullrich Horlacher Server und Virtualisierung Rechenzentrum IZUS/TIK E-Mail: horlacher at tik.uni-stuttgart.de Universitaet Stuttgart Tel: ++49-711-68565868 Allmandring 30a Fax: ++49-711-682357 70550 Stuttgart (Germany) WWW: http://www.tik.uni-stuttgart.de/ REF:<20151215081915.GB29648 at rus.uni-stuttgart.de> From framstag at rus.uni-stuttgart.de Tue Dec 15 05:59:41 2015 From: framstag at rus.uni-stuttgart.de (Ulli Horlacher) Date: Tue, 15 Dec 2015 11:59:41 +0100 Subject: [python-win32] drag&drop files with non-ASCII filenames? In-Reply-To: <20151215081915.GB29648@rus.uni-stuttgart.de> References: <20151215081915.GB29648@rus.uni-stuttgart.de> Message-ID: <20151215105941.GA23338@rus.uni-stuttgart.de> On Tue 2015-12-15 (09:19), Ulli Horlacher wrote: > while msvcrt.kbhit(): > c = msvcrt.getch() > if c == '\n' or c == '\r': break > paste += c I tried it with msvcrt.getwch(): same result, returns ASCII only :-( -- Ullrich Horlacher Server und Virtualisierung Rechenzentrum IZUS/TIK E-Mail: horlacher at tik.uni-stuttgart.de Universitaet Stuttgart Tel: ++49-711-68565868 Allmandring 30a Fax: ++49-711-682357 70550 Stuttgart (Germany) WWW: http://www.tik.uni-stuttgart.de/ REF:<20151215081915.GB29648 at rus.uni-stuttgart.de> From timr at probo.com Tue Dec 15 14:10:43 2015 From: timr at probo.com (Tim Roberts) Date: Tue, 15 Dec 2015 11:10:43 -0800 Subject: [python-win32] drag&drop files with non-ASCII filenames? In-Reply-To: <20151215081915.GB29648@rus.uni-stuttgart.de> References: <20151215081915.GB29648@rus.uni-stuttgart.de> Message-ID: <567065B3.3070306@probo.com> Ulli Horlacher wrote: > I have a python 2.7 program which runs in a console window and upload > files. > To specify the files, the user uses Windows drag&drop (via explorer) or > copy&paste. This is hopeless. In addition to the normal difficulties in string/Unicode conversions, you have the added limitations of the current console code page. You simply cannot type characters in a Windows console that are not present in your current code page. You need to make this a GUI app, not a console app. Your code is also making assumptions about the behavior of the console window that are not warranted. No one promised, for example, that a string pasted with "paste" is going to fire kbhit() continuously until empty. > To read it I use: > > file = get_paste() It is unwise to use the name of a built-in type as the name of a variable. -- Tim Roberts, timr at probo.com Providenza & Boekelheide, Inc. From framstag at rus.uni-stuttgart.de Tue Dec 15 14:42:20 2015 From: framstag at rus.uni-stuttgart.de (Ulli Horlacher) Date: Tue, 15 Dec 2015 20:42:20 +0100 Subject: [python-win32] drag&drop files with non-ASCII filenames? In-Reply-To: <567065B3.3070306@probo.com> References: <20151215081915.GB29648@rus.uni-stuttgart.de> <567065B3.3070306@probo.com> Message-ID: <20151215194220.GA30031@rus.uni-stuttgart.de> On Tue 2015-12-15 (11:10), Tim Roberts wrote: > > I have a python 2.7 program which runs in a console window and upload > > files. > > To specify the files, the user uses Windows drag&drop (via explorer) or > > copy&paste. > > This is hopeless. In addition to the normal difficulties in > string/Unicode conversions, you have the added limitations of the > current console code page. You simply cannot type characters in a > Windows console that are not present in your current code page. What is the current code page? drag&drop of a file with a non-ASCII filename from the explorer into a "naked" console window works: http://fex.rus.uni-stuttgart.de/fop/dLxrxPBV/X-201512152036.png Is there no way to catch it with Python? > Your code is also making assumptions about the behavior of the console > window that are not warranted. No one promised, for example, that a > string pasted with "paste" is going to fire kbhit() continuously until > empty. So far, it works :-) > > To read it I use: > > > > file = get_paste() > > It is unwise to use the name of a built-in type as the name of a variable. Ooops. True. -- Ullrich Horlacher Server und Virtualisierung Rechenzentrum IZUS/TIK E-Mail: horlacher at tik.uni-stuttgart.de Universitaet Stuttgart Tel: ++49-711-68565868 Allmandring 30a Fax: ++49-711-682357 70550 Stuttgart (Germany) WWW: http://www.tik.uni-stuttgart.de/ REF:<567065B3.3070306 at probo.com> From timr at probo.com Tue Dec 15 15:27:37 2015 From: timr at probo.com (Tim Roberts) Date: Tue, 15 Dec 2015 12:27:37 -0800 Subject: [python-win32] drag&drop files with non-ASCII filenames? In-Reply-To: <20151215194220.GA30031@rus.uni-stuttgart.de> References: <20151215081915.GB29648@rus.uni-stuttgart.de> <567065B3.3070306@probo.com> <20151215194220.GA30031@rus.uni-stuttgart.de> Message-ID: <567077B9.3040806@probo.com> Ulli Horlacher wrote: > On Tue 2015-12-15 (11:10), Tim Roberts wrote: > >>> I have a python 2.7 program which runs in a console window and upload files. >>> To specify the files, the user uses Windows drag&drop (via explorer) or copy&paste. >> This is hopeless. In addition to the normal difficulties in >> string/Unicode conversions, you have the added limitations of the >> current console code page. You simply cannot type characters in a >> Windows console that are not present in your current code page. > What is the current code page? The Windows console shell is an 8-bit entity. That means you only have 256 characters available at any given time, similar to they way non-Unicode strings work in Python 2. The "code page" determines which 256 you are using. You can type "chcp" to see the current code page. By default, you get code page 437, which derived from the original IBM PC character ROMs. You simply cannot type or display characters that are not in the current code page. Using msvcrt.getchw does not convert the console to a Unicode entity. It merely means the characters you DO get are represented in Unicode. The Windows console theoretically supports a UTF-8 code page (chcp 65001), and it does fix many of these problems, but there are some console apps that won't like it. > drag&drop of a file with a non-ASCII filename from the explorer into a > "naked" console window works: > > http://fex.rus.uni-stuttgart.de/fop/dLxrxPBV/X-201512152036.png > > Is there no way to catch it with Python? There may be, as long as you can figure out the translation. What do you actually get when you try your example? I created a file on my machine called x?x.xxx, where that middle glyph is code 0xF4 in code page 437. When I drag and drop that to your program, it displayed correctly. However, everything is not perfect. If I copy that name from the console window and paste it into your app, I get x?x.xxx. Here, the middle glyph is 0x93 in code page 437, but it is U+00F4 in Unicode. Somebody converted the string to Unicode by simple widening, and then converted back to CP437. I get the same result if I paste my file name here directly: x?x.xxx -- Tim Roberts, timr at probo.com Providenza & Boekelheide, Inc. From random832 at fastmail.com Tue Dec 15 16:39:16 2015 From: random832 at fastmail.com (Random832) Date: Tue, 15 Dec 2015 16:39:16 -0500 Subject: [python-win32] drag&drop files with non-ASCII filenames? References: <20151215081915.GB29648@rus.uni-stuttgart.de> <567065B3.3070306@probo.com> <20151215194220.GA30031@rus.uni-stuttgart.de> <567077B9.3040806@probo.com> Message-ID: <87lh8v4cjf.fsf@fastmail.com> Tim Roberts writes: > The Windows console shell is an 8-bit entity. That's not true. Well, it's only true A) of programs that use 8-bit I/O instead of Unicode (which unfortunately happens to include Python, and B) when a bitmap font (i.e. Terminal) is used instead of a truetype font. Note that the bitmap font can't be changed with chcp either. > Using msvcrt.getchw does not convert the console to a Unicode > entity. It merely means the characters you DO get are > represented in Unicode. Also not true. There are certainly problems with getwch, but any unicode character that can actually be entered by a real keyboard key, even on custom layouts that contain characters not in the codepage, will work fine. The limitation is the keyboard layout, not the codepage. Even for pasted (or dropped) text, it will synthesize keyboard events it can handle if a key exists for the character... otherwise, it simulates alt-NNNN events that getwch cannot handle. If you choose, for example, a Greek keyboard layout, even Latin letters (definitely ASCII characters) can't be pasted to a getwch loop. From rays at blue-cove.com Tue Dec 15 15:54:33 2015 From: rays at blue-cove.com (R Schumacher) Date: Tue, 15 Dec 2015 12:54:33 -0800 Subject: [python-win32] drag&drop files with non-ASCII filenames? In-Reply-To: <567077B9.3040806@probo.com> References: <20151215081915.GB29648@rus.uni-stuttgart.de> <567065B3.3070306@probo.com> <20151215194220.GA30031@rus.uni-stuttgart.de> <567077B9.3040806@probo.com> Message-ID: <201512152054.tBFKscMj015073@blue-cove.com> At 12:27 PM 12/15/2015, Tim Roberts wrote: >Ulli Horlacher wrote: > > On Tue 2015-12-15 (11:10), Tim Roberts wrote: > > > >>> I have a python 2.7 program which runs in a console window and > upload files. > >>> To specify the files, the user uses Windows drag&drop (via > explorer) or copy&paste. > >> This is hopeless. In addition to the normal difficulties in > >> string/Unicode conversions, you have the added limitations of the > >> current console code page. You simply cannot type characters in a > >> Windows console that are not present in your current code page. > > What is the current code page? > >The Windows console shell is an 8-bit entity. That means you only have >256 characters available at any given time, similar to they way >non-Unicode strings work in Python 2. The "code page" determines which >256 you are using. You can type "chcp" to see the current code page. >By default, you get code page 437, which derived from the original IBM >PC character ROMs. You simply cannot type or display characters that >are not in the current code page. > >Using msvcrt.getchw does not convert the console to a Unicode entity. >It merely means the characters you DO get are represented in Unicode. > >The Windows console theoretically supports a UTF-8 code page (chcp >65001), and it does fix many of these problems, but there are some >console apps that won't like it. It is 16 bits per character There may be some confusion in that each code page is 256 codes https://msdn.microsoft.com/en-us/library/ms686013%28v=vs.85%29.aspx but pages can be switched at will Windows chcp https://technet.microsoft.com/en-us/library/bb490874.aspx good discussion http://illegalargumentexception.blogspot.com/2009/04/i18n-unicode-at-windows-command-prompt.html My Win 7 console is US default 437 https://msdn.microsoft.com/en-us/library/dd317756%28v=vs.85%29.aspx https://en.wikipedia.org/wiki/Win32_console#Windows_NT_and_Windows_CE - Ray From framstag at rus.uni-stuttgart.de Wed Dec 16 03:36:08 2015 From: framstag at rus.uni-stuttgart.de (Ulli Horlacher) Date: Wed, 16 Dec 2015 09:36:08 +0100 Subject: [python-win32] drag&drop files with non-ASCII filenames? In-Reply-To: <87lh8v4cjf.fsf@fastmail.com> References: <20151215081915.GB29648@rus.uni-stuttgart.de> <567065B3.3070306@probo.com> <20151215194220.GA30031@rus.uni-stuttgart.de> <567077B9.3040806@probo.com> <87lh8v4cjf.fsf@fastmail.com> Message-ID: <20151216083608.GB30031@rus.uni-stuttgart.de> On Tue 2015-12-15 (16:39), Random832 wrote: > > The Windows console shell is an 8-bit entity. > > That's not true. Well, it's only true A) of programs that use > 8-bit I/O instead of Unicode (which unfortunately happens to > include Python Ok, then this is a dead end for me? > The limitation is the keyboard layout, not the codepage. Even > for pasted (or dropped) text, it will synthesize keyboard events > it can handle if a key exists for the character... otherwise, it > simulates alt-NNNN events that getwch cannot handle. If you > choose, for example, a Greek keyboard layout, even Latin letters > (definitely ASCII characters) can't be pasted to a getwch loop. Even worse! Ok, then my program will offer drag&drop only as an option for ASCII filenames and the default file selection will be Tk askopenfilename() and askdirectory(). The bad thing is, the user has to decide first, whether he wants to select a file or a directory. There seems to be no Tk widget for selecting files AND directories. -- Ullrich Horlacher Server und Virtualisierung Rechenzentrum IZUS/TIK E-Mail: horlacher at tik.uni-stuttgart.de Universitaet Stuttgart Tel: ++49-711-68565868 Allmandring 30a Fax: ++49-711-682357 70550 Stuttgart (Germany) WWW: http://www.tik.uni-stuttgart.de/ REF:<87lh8v4cjf.fsf at fastmail.com> From random832 at fastmail.com Wed Dec 16 11:23:50 2015 From: random832 at fastmail.com (Random832) Date: Wed, 16 Dec 2015 11:23:50 -0500 Subject: [python-win32] drag&drop files with non-ASCII filenames? References: <20151215081915.GB29648@rus.uni-stuttgart.de> <567065B3.3070306@probo.com> <20151215194220.GA30031@rus.uni-stuttgart.de> <567077B9.3040806@probo.com> <87lh8v4cjf.fsf@fastmail.com> <20151216083608.GB30031@rus.uni-stuttgart.de> Message-ID: <87vb7yl5ux.fsf@fastmail.com> Ulli Horlacher writes: >> That's not true. Well, it's only true A) of programs that use >> 8-bit I/O instead of Unicode (which unfortunately happens to >> include Python > > Ok, then this is a dead end for me? I meant normal Python I/O (read, input, print, etc). getwch isn't exactly *not* Unicode, though you read the rest of the post discussing its problems. If you want to use a strictly console-based approach, you could simply provide a text input field for the user to type (or paste, or drop) a filename followed by pressing Enter. Your use of kbhit/getwch is intended to "automatically" detect the end of the filename without having to press enter, right? From framstag at rus.uni-stuttgart.de Wed Dec 16 11:45:12 2015 From: framstag at rus.uni-stuttgart.de (Ulli Horlacher) Date: Wed, 16 Dec 2015 17:45:12 +0100 Subject: [python-win32] drag&drop files with non-ASCII filenames? In-Reply-To: <87vb7yl5ux.fsf@fastmail.com> References: <20151215081915.GB29648@rus.uni-stuttgart.de> <567065B3.3070306@probo.com> <20151215194220.GA30031@rus.uni-stuttgart.de> <567077B9.3040806@probo.com> <87lh8v4cjf.fsf@fastmail.com> <20151216083608.GB30031@rus.uni-stuttgart.de> <87vb7yl5ux.fsf@fastmail.com> Message-ID: <20151216164512.GA16542@rus.uni-stuttgart.de> On Wed 2015-12-16 (11:23), Random832 wrote: > If you want to use a strictly console-based approach, you could > simply provide a text input field for the user to type (or > paste, or drop) a filename followed by pressing Enter. I have had this in first place and the problem was: My users dropped the file into the application window and wait forever without pressing ENTER, though it was written: "Drag&drop a file into this window and press [ENTER] to continue" > Your use of kbhit/getwch is intended to "automatically" detect the end of > the filename without having to press enter, right? Correct. -- Ullrich Horlacher Server und Virtualisierung Rechenzentrum IZUS/TIK E-Mail: horlacher at tik.uni-stuttgart.de Universitaet Stuttgart Tel: ++49-711-68565868 Allmandring 30a Fax: ++49-711-682357 70550 Stuttgart (Germany) WWW: http://www.tik.uni-stuttgart.de/ REF:<87vb7yl5ux.fsf at fastmail.com> From janssen at parc.com Wed Dec 16 12:54:40 2015 From: janssen at parc.com (Bill Janssen) Date: Wed, 16 Dec 2015 09:54:40 -0800 Subject: [python-win32] building a complicated Python application on Windows Message-ID: <17782.1450288480@parc.com> I'd like to build a Python-based deliverable for Windows. It includes many gnarly packages, like numpy, scipy, statsmodel, ggplot, kivy, ZODB, ZEO, etc. They include Cython modules (and scipy may even require Fortran, for all I know). On OS X, I build this all from source by starting with Kivy, which is packaged as a venv inside an OS X application, and add in the other stuff. But I'm not sure this is the best way to proceed on Windows (7, 8, and 10). I'm also used to using mingw on Windows, but again, I'm not sure that's appropriate. Any advice would be appreciated... Bill From trent at trent.me Wed Dec 16 13:52:42 2015 From: trent at trent.me (Trent Nelson) Date: Wed, 16 Dec 2015 18:52:42 +0000 Subject: [python-win32] building a complicated Python application on Windows In-Reply-To: <17782.1450288480@parc.com> References: <17782.1450288480@parc.com> Message-ID: <78527C66-1347-4B40-AF4A-1FF26D014802@trent.me> Conda is well suited to this. I use it to bundle all sorts of stuff on Windows. (You write recipes (see https://github.com/conda/conda-recipes for examples), then 'conda build' them, which produces a package that can be subsequently installed with conda install. Can sign up to anaconda.org and then upload the package into your own channel, such that a plain 'conda install -c janssen foobar' will install your package and all the deps (which were specified in the recipe/meta.yaml). Sent from my iPhone > On Dec 16, 2015, at 13:00, Bill Janssen wrote: > > I'd like to build a Python-based deliverable for Windows. It includes > many gnarly packages, like numpy, scipy, statsmodel, ggplot, kivy, ZODB, > ZEO, etc. They include Cython modules (and scipy may even require > Fortran, for all I know). > > On OS X, I build this all from source by starting with Kivy, which is > packaged as a venv inside an OS X application, and add in the other > stuff. But I'm not sure this is the best way to proceed on Windows (7, > 8, and 10). I'm also used to using mingw on Windows, but again, I'm > not sure that's appropriate. > > Any advice would be appreciated... > > Bill > _______________________________________________ > python-win32 mailing list > python-win32 at python.org > https://mail.python.org/mailman/listinfo/python-win32 From janssen at parc.com Wed Dec 16 20:05:01 2015 From: janssen at parc.com (Bill Janssen) Date: Wed, 16 Dec 2015 17:05:01 -0800 Subject: [python-win32] building a complicated Python application on Windows In-Reply-To: <78527C66-1347-4B40-AF4A-1FF26D014802@trent.me> References: <17782.1450288480@parc.com> <78527C66-1347-4B40-AF4A-1FF26D014802@trent.me> Message-ID: <30084.1450314301@parc.com> Trent Nelson wrote: > Conda is well suited to this. I use it to bundle all sorts of stuff on Windows. Thanks, Trent. That looks possible. Though the documentation is a bit crufty; "source activate foo" doesn't do much on my Mac, because "activate" isn't a script in the current directory. Bill > (You write recipes (see https://github.com/conda/conda-recipes for examples), then 'conda build' them, which produces a package that can be subsequently installed with conda install. Can sign up to anaconda.org and then upload the package into your own channel, such that a plain 'conda install -c janssen foobar' will install your package and all the deps (which were specified in the recipe/meta.yaml). > > Sent from my iPhone > > > On Dec 16, 2015, at 13:00, Bill Janssen wrote: > > > > I'd like to build a Python-based deliverable for Windows. It includes > > many gnarly packages, like numpy, scipy, statsmodel, ggplot, kivy, ZODB, > > ZEO, etc. They include Cython modules (and scipy may even require > > Fortran, for all I know). > > > > On OS X, I build this all from source by starting with Kivy, which is > > packaged as a venv inside an OS X application, and add in the other > > stuff. But I'm not sure this is the best way to proceed on Windows (7, > > 8, and 10). I'm also used to using mingw on Windows, but again, I'm > > not sure that's appropriate. > > > > Any advice would be appreciated... > > > > Bill > > _______________________________________________ > > python-win32 mailing list > > python-win32 at python.org > > https://mail.python.org/mailman/listinfo/python-win32 From rays at blue-cove.com Wed Dec 16 21:04:24 2015 From: rays at blue-cove.com (R Schumacher) Date: Wed, 16 Dec 2015 18:04:24 -0800 Subject: [python-win32] building a complicated Python application on Windows In-Reply-To: <30084.1450314301@parc.com> References: <17782.1450288480@parc.com> <78527C66-1347-4B40-AF4A-1FF26D014802@trent.me> <30084.1450314301@parc.com> Message-ID: <201512170204.tBH24Srt016814@blue-cove.com> I agree on the Conda suggestion. If you haven't used Gohlke's Windows libraries at UCI http://www.lfd.uci.edu/~gohlke/pythonlibs/ you can look there as well. All are Intel MKL optimized when possible (as is Enthought's distro) - Ray At 05:05 PM 12/16/2015, Bill Janssen wrote: >Trent Nelson wrote: > > > Conda is well suited to this. I use it to bundle all sorts of > stuff on Windows. > >Thanks, Trent. That looks possible. Though the documentation is a bit >crufty; "source activate foo" doesn't do much on my Mac, because >"activate" isn't a script in the current directory. > >Bill > > > (You write recipes (see https://github.com/conda/conda-recipes > for examples), then 'conda build' them, which produces a package > that can be subsequently installed with conda install. Can sign up > to anaconda.org and then upload the package into your own channel, > such that a plain 'conda install -c janssen foobar' will install > your package and all the deps (which were specified in the recipe/meta.yaml). > > > > Sent from my iPhone > > > > > On Dec 16, 2015, at 13:00, Bill Janssen wrote: > > > > > > I'd like to build a Python-based deliverable for Windows. It includes > > > many gnarly packages, like numpy, scipy, statsmodel, ggplot, kivy, ZODB, > > > ZEO, etc. They include Cython modules (and scipy may even require > > > Fortran, for all I know). > > > > > > On OS X, I build this all from source by starting with Kivy, which is > > > packaged as a venv inside an OS X application, and add in the other > > > stuff. But I'm not sure this is the best way to proceed on Windows (7, > > > 8, and 10). I'm also used to using mingw on Windows, but again, I'm > > > not sure that's appropriate. > > > > > > Any advice would be appreciated... > > > > > > Bill > > > _______________________________________________ > > > python-win32 mailing list > > > python-win32 at python.org > > > https://mail.python.org/mailman/listinfo/python-win32 >_______________________________________________ >python-win32 mailing list >python-win32 at python.org >https://mail.python.org/mailman/listinfo/python-win32 From eryksun at gmail.com Wed Dec 16 21:56:27 2015 From: eryksun at gmail.com (eryk sun) Date: Wed, 16 Dec 2015 20:56:27 -0600 Subject: [python-win32] drag&drop files with non-ASCII filenames? In-Reply-To: <567077B9.3040806@probo.com> References: <20151215081915.GB29648@rus.uni-stuttgart.de> <567065B3.3070306@probo.com> <20151215194220.GA30031@rus.uni-stuttgart.de> <567077B9.3040806@probo.com> Message-ID: On Tue, Dec 15, 2015 at 2:27 PM, Tim Roberts wrote: > > The Windows console shell is an 8-bit entity. That means you only have > 256 characters available at any given time, similar to they way > non-Unicode strings work in Python 2. The input and screen buffers of the console (conhost.exe) are UCS-2, which has been the case since NT 3.1 was released in 1993. There are display limits, such as not being able to mix narrow and wide glyphs and not handling characters composed with multiple codes (such as UTF-16 surrogate pairs). Regardless of what's displayed, the wide-character API preserves the underlying UTF-16 text. That said, handling the input buffer requires special care due to how it represents characters that aren't mapped by the current keyboard layout. In this case, the WindowProc of conhost.exe handles a WM_DROPFILES [1] message as if it's pasted from the clipboard. It loops over the string to create an INPUT_RECORD [2] array. Each character is mapped in the current keyboard layout via VkKeyScan [3]. If this fails, the console uses a sequence of Alt+Numpad key event records. (At the end of this reply I'm including a commented transcript of a session with a debugger attached to conhost.exe in Windows 10. I set a breakpoint on s_DoStringPaste to watch how it handled pasting "?" into the input buffer.) A client program that calls ReadConsoleW [4] doesn't have to worry about this. The console internally handles decoding the Alt+Numpad sequence when it writes the input to the caller's wide-character buffer. Microsoft's getwch function instead calls ReadConsoleInputW [5] to be able to read extended keys and avoid discarding non-keyboard events, but it doesn't handle the Alt+Numpad case. Handling these sequences requires a custom implementation of kbhit and getwch. An example that gets this right is the PDCurses [6] library, when compiled using the wide-character API. Christoph Gohlke has a Python curses module [7] for Windows that uses PDCurses, but only the Python 3 version is compiled with Unicode support. If extended key support (e.g. arrow and function keys) and preserving mouse, window buffer, and focus events doesn't matter, then just disable the console's line input and echo mode, and call ReadConsoleW to read a character at a time. This lets the console handle the Alt+Numpad events for you. Here's example ctypes code for this limited implementation of kbhit and getwch. It's not broadly tested, so caveat emptor. I did check that it worked with file drops and pasting Unicode strings into the console, as well as manual Alt+Numpad input. import msvcrt import ctypes from ctypes import wintypes kernel32 = ctypes.WinDLL('kernel32', use_last_error=True) STD_INPUT_HANDLE = -10 KEY_EVENT = 1 VK_MENU = 0x12 ENABLE_LINE_INPUT = 2 ENABLE_ECHO_INPUT = 4 wintypes.CHAR = ctypes.c_char class INPUT_RECORD(ctypes.Structure): class EVENT_RECORD(ctypes.Union): class KEY_EVENT_RECORD(ctypes.Structure): class UCHAR(ctypes.Union): _fields_ = (('UnicodeChar', wintypes.WCHAR), ('AsciiChar', wintypes.CHAR)) _fields_ = (('bKeyDown', wintypes.BOOL), ('wRepeatCount', wintypes.WORD), ('wVirtualKeyCode', wintypes.WORD), ('wVirtualScanCode', wintypes.WORD), ('uChar', UCHAR), ('dwControlKeyState', wintypes.DWORD)) _fields_ = (('KeyEvent', KEY_EVENT_RECORD),) _fields_ = (('EventType', wintypes.WORD), ('Event', EVENT_RECORD)) def kbhit(): handle = kernel32.GetStdHandle(STD_INPUT_HANDLE) npend = wintypes.DWORD() npeek = wintypes.DWORD() if (not kernel32.GetNumberOfConsoleInputEvents( handle, ctypes.byref(npend)) or npend.value == 0): return False inbuf = (INPUT_RECORD * npend.value)() if (not kernel32.PeekConsoleInputW( handle, inbuf, npend, ctypes.byref(npeek)) or npeek.value == 0): return False peek = (INPUT_RECORD * npeek.value).from_buffer(inbuf) for p in peek: if p.EventType != KEY_EVENT: continue e = p.Event.KeyEvent if (e.bKeyDown or (e.wVirtualKeyCode == VK_MENU and e.uChar.UnicodeChar)): return True return False def getwch(): handle = kernel32.GetStdHandle(STD_INPUT_HANDLE) old_mode = wintypes.DWORD() if not kernel32.GetConsoleMode(handle, ctypes.byref(old_mode)): raise ctypes.WinError(ctypes.get_last_error()) mode = old_mode.value & ~(ENABLE_LINE_INPUT | ENABLE_ECHO_INPUT) kernel32.SetConsoleMode(handle, mode) try: wc = wintypes.WCHAR() n = wintypes.DWORD() if not kernel32.ReadConsoleW( handle, ctypes.byref(wc), 1, ctypes.byref(n), None): raise ctypes.WinError(ctypes.get_last_error()) return wc.value finally: kernel32.SetConsoleMode(handle, old_mode) > Using msvcrt.getchw does not convert the console to a Unicode entity. > It merely means the characters you DO get are represented in Unicode. FYI, the CRT source code is distributed with Visual Studio. For example, with Windows 10 and Visual Studio 2015, it should be installed here: _getch, _kbhit %ProgramFiles(x86)%\Windows Kits\10\Source\10.0.10150.0\ucrt\conio\getch.cpp _getwch %ProgramFiles(x86)%\Windows Kits\10\Source\10.0.10150.0\ucrt\conio\getwch.cpp So there's no mystery about what these functions do. The mystery that requires digging into the debugger is how conhost.exe implements the public console API. Thankfully Microsoft's symbol server publishes the (public) conhost symbols, so it's relatively easy to find interesting functions to break on. > The Windows console theoretically supports a UTF-8 code page (chcp > 65001), and it does fix many of these problems, but there are some > console apps that won't like it. The console itself doesn't support codepage 65001 (UTF-8) well at all. Depending on the version of Windows, conhost.exe (or csrss.exe prior to Win 7) has several bugs and shortcomings with this codepage. For example: * For reading from the console, all versions I've used fail to correctly encode non-ASCII characters as UTF-8 via WideCharToMultibyte. If you request 10 bytes, it attempts to encode 10 characters, which fails for non-ASCII UTF-8. Instead of trying to dynamically step down the number of characters, it returns to the client that it 'successfully' read 0 bytes. This generally gets interpreted as EOF. For example, Python's REPL quits, and input() raise EOFError. * A buffered writer might flush and split a 2-4 byte UTF-8 sequence into two separate writes. But the console doesn't maintain the state of partially written characters (or reads if the above bug wasn't there). Instead you'll end up with 2-4 U+FFFD replacement characters written to the console. * Prior to Windows 8, WriteFile to the console incorrectly reports the number of Unicode characters written instead of the number of bytes. So buffered writers will loop repeatedly writing what they think is the remainder of the UTF-8 buffer. This causes a potentially long trail of junk text to be printed after every buffered write that contains non-ASCII characters. As mentioned above, here's the debug session with a breakpoint set on ConhostV2!Clipboard::s_DoStringPaste. (conhostv2.dll was added in Windows 10, as part of the update of the console interface. It seems they're modularizing and modernizing the design using C++ classes, perhaps to accommodate more improvements in future releases?) To follow this it helps to have a basic understanding of Microsoft's debugger commands [8] and x64 register usage [9]. Breakpoint 0 hit ConhostV2!Clipboard::s_DoStringPaste: 00007ffb`11086120 4885c9 test rcx,rcx 0:001> pc Allocate memory for the INPUT_RECORD array: ConhostV2!Clipboard::s_DoStringPaste+0x51: 00007ffb`11086171 ff1501470200 call qword ptr [ ConhostV2!_imp_RtlAllocateHeap (00007ffb`110aa878)] ds:00007ffb`110aa878={ ntdll!RtlAllocateHeap (00007ffb`1c6aebf0)} VkKeyScanW returns -1 (0xffff) because the character isn't mapped in the keyboard layout: 0:001> pc ConhostV2!Clipboard::s_DoStringPaste+0x122: 00007ffb`11086242 ff1520420200 call qword ptr [ ConhostV2!_imp_VkKeyScanW (00007ffb`110aa468)] ds:00007ffb`110aa468={ USER32!VkKeyScanW (00007ffb`1a6f6dc0)} 0:001> p; r rax rax=ffffffffffffffff So convert the character to the closest OEM character to create an Alt+Numpad sequence. Note that the OEM character is just for the sequence. The actual Unicode character is stored in the Alt key (VK_MENU) release event. 0:001> pc ConhostV2!Clipboard::s_DoStringPaste+0x1a9: 00007ffb`110862c9 e8cecd0000 call ConhostV2!ConvertToOem (00007ffb`1109309c) 0:001> ? @rcx Evaluate expression: 437 = 00000000`000001b5 0:001> du @rdx l1 000000d3`1935f850 "?" 0:001> r r9 r9=000000d31935f840 The closest character to L'?' in codepage 437 is ASCII 'A': 0:001> p; da d31935f840 l1 000000d3`1935f840 "A" Call _itoa_s to get the base 10 representation of the ordinal value of 'A' as the string "65": 0:001> pc ConhostV2!Clipboard::s_DoStringPaste+0x1c0: 00007ffb`110862e0 ff15d2440200 call qword ptr [ ConhostV2!_imp__itoa_s (00007ffb`110aa7b8)] ds:00007ffb`110aa7b8={ msvcrt!itoa_s (00007ffb`1c042af0)} 0:001> ?? (char)@rcx char 0n65 'A' 0:001> r rdx rdx=000000d31935f7c4 0:001> p; da d31935f7c4 000000d3`1935f7c4 "65" Create events for entering 6 and 5 on the numeric keypad. The corresponding wVirtualKeyCode values are VK_NUMPAD6 and VK_NUMPAD5. Also get the keyboard scan codes by calling MapVirtualKeyW. Call MapVirtualKeyW to get the wVirtualScanCode for VK_NUMPAD6: 0:001> pc ConhostV2!Clipboard::s_DoStringPaste+0x21c: 00007ffb`1108633c ff151e410200 call qword ptr [ ConhostV2!_imp_MapVirtualKeyW (00007ffb`110aa460)] ds:00007ffb`110aa460={ USER32!MapVirtualKeyW (00007ffb`1a6f3e00)} 0:001> r rcx rcx=0000000000000066 Call MapVirtualKeyW to get the wVirtualScanCode for VK_NUMPAD5: 0:001> pc ConhostV2!Clipboard::s_DoStringPaste+0x21c: 00007ffb`1108633c ff151e410200 call qword ptr [ ConhostV2!_imp_MapVirtualKeyW (00007ffb`110aa460)] ds:00007ffb`110aa460={ USER32!MapVirtualKeyW (00007ffb`1a6f3e00)} 0:001> r rcx rcx=0000000000000065 0:001> pc Write the INPUT_RECORD array to the input buffer. ConhostV2!Clipboard::s_DoStringPaste+0x3e8: 00007ffb`11086508 e87b66ffff call ConhostV2!WriteInputBuffer (00007ffb`1107cb88) This writes an array with 6 records: 0:001> r r8 r8=0000000000000006 Each record is 20 (0x14) bytes. VK_MENU (0x12) pressed: 0:001> dw (@rdx + 0*14) la 000000d3`16dc9010 0001 16df 0001 0000 0001 0012 0038 0000 000000d3`16dc9020 0002 0000 VK_NUMPAD6 (0x66) pressed: 0:001> dw (@rdx + 1*14) la 000000d3`16dc9024 0001 0000 0001 0000 0001 0066 004d 0000 000000d3`16dc9034 0002 0000 VK_NUMPAD6 (0x66) released: 0:001> dw (@rdx + 2*14) la 000000d3`16dc9038 0001 3474 0000 0000 0001 0066 004d 0000 000000d3`16dc9048 0002 0000 VK_NUMPAD5 (0x65) pressed: 0:001> dw (@rdx + 3*14) la 000000d3`16dc904c 0001 0000 0001 0000 0001 0065 004c 0000 000000d3`16dc905c 0002 0000 VK_NUMPAD5 (0x65) released: 0:001> dw (@rdx + 4*14) la 000000d3`16dc9060 0001 0000 0000 0000 0001 0065 004c 0000 000000d3`16dc9070 0002 0000 VK_MENU (0x12) released; UnicodeChar == U+00C0: 0:001> dw (@rdx + 5*14) la 000000d3`16dc9074 0001 0000 0000 0000 0001 0012 0038 00c0 000000d3`16dc9084 0000 0000 [1]: https://msdn.microsoft.com/en-us/library/bb774303 [2]: https://msdn.microsoft.com/en-us/library/ms683499 [3]: https://msdn.microsoft.com/en-us/library/ms646329 [4]: https://msdn.microsoft.com/en-us/library/ms684958 [5]: https://msdn.microsoft.com/en-us/library/ms684961 [6]: http://pdcurses.sourceforge.net [7]: http://www.lfd.uci.edu/~gohlke/pythonlibs/#curses [8]: https://msdn.microsoft.com/en-us/library/ff540507 [9]: https://msdn.microsoft.com/en-us/library/9z1stfyw From janssen at parc.com Fri Dec 18 20:02:21 2015 From: janssen at parc.com (Bill Janssen) Date: Fri, 18 Dec 2015 17:02:21 -0800 Subject: [python-win32] building a complicated Python application on Windows In-Reply-To: <78527C66-1347-4B40-AF4A-1FF26D014802@trent.me> References: <17782.1450288480@parc.com> <78527C66-1347-4B40-AF4A-1FF26D014802@trent.me> Message-ID: <21840.1450486941@parc.com> Hmmm, I'm getting an error message from 'conda build': Warning: Couldn't find Visual Studio: 'C:\\Program Files (x86)\\Common Files\\Microsoft\\Vi...' So I guess installing conda-build doesn't do everything it needs to? How would I know which version of Visual Studio to install, and where to find it? Bill Trent Nelson wrote: > Conda is well suited to this. I use it to bundle all sorts of stuff on Windows. (You write recipes (see https://github.com/conda/conda-recipes for examples), then 'conda build' them, which produces a package that can be subsequently installed with conda install. Can sign up to anaconda.org and then upload the package into your own channel, such that a plain 'conda install -c janssen foobar' will install your package and all the deps (which were specified in the recipe/meta.yaml). > > Sent from my iPhone > > > On Dec 16, 2015, at 13:00, Bill Janssen wrote: > > > > I'd like to build a Python-based deliverable for Windows. It includes > > many gnarly packages, like numpy, scipy, statsmodel, ggplot, kivy, ZODB, > > ZEO, etc. They include Cython modules (and scipy may even require > > Fortran, for all I know). > > > > On OS X, I build this all from source by starting with Kivy, which is > > packaged as a venv inside an OS X application, and add in the other > > stuff. But I'm not sure this is the best way to proceed on Windows (7, > > 8, and 10). I'm also used to using mingw on Windows, but again, I'm > > not sure that's appropriate. > > > > Any advice would be appreciated... > > > > Bill > > _______________________________________________ > > python-win32 mailing list > > python-win32 at python.org > > https://mail.python.org/mailman/listinfo/python-win32 From trent at trent.me Fri Dec 18 20:10:04 2015 From: trent at trent.me (Trent Nelson) Date: Sat, 19 Dec 2015 01:10:04 +0000 Subject: [python-win32] building a complicated Python application on Windows In-Reply-To: <21840.1450486941@parc.com> References: <17782.1450288480@parc.com> <78527C66-1347-4B40-AF4A-1FF26D014802@trent.me> <21840.1450486941@parc.com> Message-ID: Ah, so that's just the error that `python setup.py build` would have returned, it's not specific to conda-build. As for what version you need, that's where things get fun: - Python 2.7 = Visual Studio 2008 - Python 3.0->3.4 = Visual Studio 2010 - Python 3.5+ = Visual Studio 2015 For 2.7, Microsoft released this handy little bundle (thanks Steve Dower!): https://www.microsoft.com/en-us/download/details.aspx?id=44266 I've been lucky enough to always have MSDN subscriptions and full VS installations so I'm not sure how your mileage will fair with the community/free editions. You could sign up for an AppVeyor or Anaconda account if procuring VS proves problematic. Trent. -----Original Message----- From: Bill Janssen [mailto:janssen at parc.com] Sent: Friday, December 18, 2015 8:02 PM To: Trent Nelson Cc: python-win32 at python.org; janssen at parc.com Subject: Re: [python-win32] building a complicated Python application on Windows Hmmm, I'm getting an error message from 'conda build': Warning: Couldn't find Visual Studio: 'C:\\Program Files (x86)\\Common Files\\Microsoft\\Vi...' So I guess installing conda-build doesn't do everything it needs to? How would I know which version of Visual Studio to install, and where to find it? Bill Trent Nelson wrote: > Conda is well suited to this. I use it to bundle all sorts of stuff on Windows. (You write recipes (see https://github.com/conda/conda-recipes for examples), then 'conda build' them, which produces a package that can be subsequently installed with conda install. Can sign up to anaconda.org and then upload the package into your own channel, such that a plain 'conda install -c janssen foobar' will install your package and all the deps (which were specified in the recipe/meta.yaml). > > Sent from my iPhone > > > On Dec 16, 2015, at 13:00, Bill Janssen wrote: > > > > I'd like to build a Python-based deliverable for Windows. It > > includes many gnarly packages, like numpy, scipy, statsmodel, > > ggplot, kivy, ZODB, ZEO, etc. They include Cython modules (and > > scipy may even require Fortran, for all I know). > > > > On OS X, I build this all from source by starting with Kivy, which > > is packaged as a venv inside an OS X application, and add in the > > other stuff. But I'm not sure this is the best way to proceed on > > Windows (7, 8, and 10). I'm also used to using mingw on Windows, > > but again, I'm not sure that's appropriate. > > > > Any advice would be appreciated... > > > > Bill > > _______________________________________________ > > python-win32 mailing list > > python-win32 at python.org > > https://mail.python.org/mailman/listinfo/python-win32 From janssen at parc.com Fri Dec 18 21:12:25 2015 From: janssen at parc.com (Bill Janssen) Date: Fri, 18 Dec 2015 18:12:25 -0800 Subject: [python-win32] building a complicated Python application on Windows In-Reply-To: References: <17782.1450288480@parc.com> <78527C66-1347-4B40-AF4A-1FF26D014802@trent.me> <21840.1450486941@parc.com> Message-ID: <23915.1450491145@parc.com> Trent Nelson wrote: > Ah, so that's just the error that `python setup.py build` would have returned, it's not specific to conda-build. > > As for what version you need, that's where things get fun: > - Python 2.7 = Visual Studio 2008 > - Python 3.0->3.4 = Visual Studio 2010 > - Python 3.5+ = Visual Studio 2015 > > For 2.7, Microsoft released this handy little bundle (thanks Steve Dower!): https://www.microsoft.com/en-us/download/details.aspx?id=44266 I installed this and it still doesn't work. Just spent an hour researching it, and I've got to tell you, I can't believe we let ourselves into this situation. It's really bad. The code in distutils/msvc9compiler.py insists that even if you set the env var VS90COMNTOOLS to point to your installation, it still has to be in a subdirectory called "VC", which the the Microsoft bundle doesn't do. "vcvarsall.bat" winds up in "~/AppData/Local/Programs/Common/Microsoft/Visual C++ for Python/9.0/vcvarsall.bat". And the Microsoft bundle doesn't set any of the registry keys msvc9compiler.py looks for, so it can't find it that way. I went down into the installed VC, copied vcvarsall.bat to be where msvc9compiler.py wanted to find it, set the env var, and finally got it. This is nasty. Bill > > I've been lucky enough to always have MSDN subscriptions and full VS installations so I'm not sure how your mileage will fair with the community/free editions. You could sign up for an AppVeyor or Anaconda account if procuring VS proves problematic. > > Trent. > > -----Original Message----- > From: Bill Janssen [mailto:janssen at parc.com] > Sent: Friday, December 18, 2015 8:02 PM > To: Trent Nelson > Cc: python-win32 at python.org; janssen at parc.com > Subject: Re: [python-win32] building a complicated Python application on Windows > > Hmmm, I'm getting an error message from 'conda build': > > Warning: Couldn't find Visual Studio: 'C:\\Program Files (x86)\\Common Files\\Microsoft\\Vi...' > > So I guess installing conda-build doesn't do everything it needs to? > How would I know which version of Visual Studio to install, and where to find it? > > Bill > > Trent Nelson wrote: > > > Conda is well suited to this. I use it to bundle all sorts of stuff on Windows. (You write recipes (see https://github.com/conda/conda-recipes for examples), then 'conda build' them, which produces a package that can be subsequently installed with conda install. Can sign up to anaconda.org and then upload the package into your own channel, such that a plain 'conda install -c janssen foobar' will install your package and all the deps (which were specified in the recipe/meta.yaml). > > > > Sent from my iPhone > > > > > On Dec 16, 2015, at 13:00, Bill Janssen wrote: > > > > > > I'd like to build a Python-based deliverable for Windows. It > > > includes many gnarly packages, like numpy, scipy, statsmodel, > > > ggplot, kivy, ZODB, ZEO, etc. They include Cython modules (and > > > scipy may even require Fortran, for all I know). > > > > > > On OS X, I build this all from source by starting with Kivy, which > > > is packaged as a venv inside an OS X application, and add in the > > > other stuff. But I'm not sure this is the best way to proceed on > > > Windows (7, 8, and 10). I'm also used to using mingw on Windows, > > > but again, I'm not sure that's appropriate. > > > > > > Any advice would be appreciated... > > > > > > Bill > > > _______________________________________________ > > > python-win32 mailing list > > > python-win32 at python.org > > > https://mail.python.org/mailman/listinfo/python-win32 From trent at trent.me Sat Dec 19 06:47:33 2015 From: trent at trent.me (Trent Nelson) Date: Sat, 19 Dec 2015 11:47:33 +0000 Subject: [python-win32] building a complicated Python application on Windows In-Reply-To: <23915.1450491145@parc.com> References: <17782.1450288480@parc.com> <78527C66-1347-4B40-AF4A-1FF26D014802@trent.me> <21840.1450486941@parc.com> <23915.1450491145@parc.com> Message-ID: Heh, yeah, it's one of those things that's painful when you're going through it the first time, but once you get over the hump, everything generally just works. It really comes down to the different C runtimes and needing to make sure what Python thinks is a FILE* is the same thing some C extension module things is a FILE*, the thing that calls free() matches with the thing that called malloc(), etc. It'd be neat if we didn't link to the C runtime at all and just used all the functionality provided by Rtl/kernel32/ntdll, as it would avoid all of this, and you could use any compiler you want. But it's a bit late for that ;-) Trent. -----Original Message----- From: Bill Janssen [mailto:janssen at parc.com] Sent: Friday, December 18, 2015 9:12 PM To: Trent Nelson Cc: python-win32 at python.org; janssen at parc.com Subject: Re: [python-win32] building a complicated Python application on Windows Trent Nelson wrote: > Ah, so that's just the error that `python setup.py build` would have returned, it's not specific to conda-build. > > As for what version you need, that's where things get fun: > - Python 2.7 = Visual Studio 2008 > - Python 3.0->3.4 = Visual Studio 2010 > - Python 3.5+ = Visual Studio 2015 > > For 2.7, Microsoft released this handy little bundle (thanks Steve > Dower!): > https://www.microsoft.com/en-us/download/details.aspx?id=44266 I installed this and it still doesn't work. Just spent an hour researching it, and I've got to tell you, I can't believe we let ourselves into this situation. It's really bad. The code in distutils/msvc9compiler.py insists that even if you set the env var VS90COMNTOOLS to point to your installation, it still has to be in a subdirectory called "VC", which the the Microsoft bundle doesn't do. "vcvarsall.bat" winds up in "~/AppData/Local/Programs/Common/Microsoft/Visual C++ for Python/9.0/vcvarsall.bat". And the Microsoft bundle doesn't set any of the registry keys msvc9compiler.py looks for, so it can't find it that way. I went down into the installed VC, copied vcvarsall.bat to be where msvc9compiler.py wanted to find it, set the env var, and finally got it. This is nasty. Bill > > I've been lucky enough to always have MSDN subscriptions and full VS installations so I'm not sure how your mileage will fair with the community/free editions. You could sign up for an AppVeyor or Anaconda account if procuring VS proves problematic. > > Trent. > > -----Original Message----- > From: Bill Janssen [mailto:janssen at parc.com] > Sent: Friday, December 18, 2015 8:02 PM > To: Trent Nelson > Cc: python-win32 at python.org; janssen at parc.com > Subject: Re: [python-win32] building a complicated Python application > on Windows > > Hmmm, I'm getting an error message from 'conda build': > > Warning: Couldn't find Visual Studio: 'C:\\Program Files (x86)\\Common Files\\Microsoft\\Vi...' > > So I guess installing conda-build doesn't do everything it needs to? > How would I know which version of Visual Studio to install, and where to find it? > > Bill > > Trent Nelson wrote: > > > Conda is well suited to this. I use it to bundle all sorts of stuff on Windows. (You write recipes (see https://github.com/conda/conda-recipes for examples), then 'conda build' them, which produces a package that can be subsequently installed with conda install. Can sign up to anaconda.org and then upload the package into your own channel, such that a plain 'conda install -c janssen foobar' will install your package and all the deps (which were specified in the recipe/meta.yaml). > > > > Sent from my iPhone > > > > > On Dec 16, 2015, at 13:00, Bill Janssen wrote: > > > > > > I'd like to build a Python-based deliverable for Windows. It > > > includes many gnarly packages, like numpy, scipy, statsmodel, > > > ggplot, kivy, ZODB, ZEO, etc. They include Cython modules (and > > > scipy may even require Fortran, for all I know). > > > > > > On OS X, I build this all from source by starting with Kivy, which > > > is packaged as a venv inside an OS X application, and add in the > > > other stuff. But I'm not sure this is the best way to proceed on > > > Windows (7, 8, and 10). I'm also used to using mingw on Windows, > > > but again, I'm not sure that's appropriate. > > > > > > Any advice would be appreciated... > > > > > > Bill > > > _______________________________________________ > > > python-win32 mailing list > > > python-win32 at python.org > > > https://mail.python.org/mailman/listinfo/python-win32 From tarun.kap at gmail.com Wed Dec 23 19:45:33 2015 From: tarun.kap at gmail.com (Tarun Kapoor) Date: Wed, 23 Dec 2015 18:45:33 -0600 Subject: [python-win32] Excel to python COM not working. Please help! Message-ID: I am supporting this old legacy code that someone else wrote. A user had their computer replaced and the code stopped working. We have some code written in python that we want to access from Excel. We register the python COM like shown below class COMWSdbAccess: _reg_clsid_ = "{505D2E5B-17EC-426D-AB60-34CDA795B37C}" _reg_desc_ = "WS DB Access COM Server 0.1" _reg_progid_ = "WSdbAccess" _reg_clsctx = pythoncom.CLSCTX_LOCAL_SERVER _public_methods_ = ['wsdbReadAllPrice'] def __init__(self): from wsdb import ws_sec_value_cusip_sel def wsdbReadAllPrice(self, FieldName, Source, PosDt, PrcDt): from wsdb import ws_sec_value_all_sel, wsMarketOpen, wsMarketClose curConn = wsMarketOpen() results = ws_sec_value_all_sel (curConn, str(FieldName), str(Source), str(PosDt), str(PrcDt)) wsMarketClose(curConn) return results if __name__ == '__main__': import win32com.server.register win32com.server.register.UseCommandLine(COMWSdbAccess) Just for the sake of testing, I have these 2 lines of code behind a button in Excel Dim dbServer As Variant Set dbServer = CreateObject("WSdbAccess") And i get the error ""The specified module could not be found" on the second line of the code. It does work from all other computers. The environment is Windows 7 64 bit computers with 32 bit excel and 32 bit python 2.7. I have opened the registry and WSdbAccess does exist. I have compared the registry of the new computer with the old computers and its the same.. PLEASE HELP. -------------- next part -------------- An HTML attachment was scrubbed... URL: From erickblender at gmail.com Fri Dec 25 11:47:00 2015 From: erickblender at gmail.com (Erick Blender) Date: Fri, 25 Dec 2015 18:47:00 +0200 Subject: [python-win32] pip not running in windows 64 Message-ID: Hi there, first time, here I m on windows 7 i m trying to build a manual (http://blender.org/manual/about/install/windows.html) when i run C:\Python34\Scripts\pip install -r requirements.txt in the cmd, The cmd hangs and doesn't respond. I just set the var path, can i get some help? -------------- next part -------------- An HTML attachment was scrubbed... URL: From vernondcole at gmail.com Sat Dec 26 11:44:33 2015 From: vernondcole at gmail.com (Vernon D. Cole) Date: Sat, 26 Dec 2015 09:44:33 -0700 Subject: [python-win32] pip not running in windows 64 In-Reply-To: References: Message-ID: Dear Erick: I assume that you do not usually use the Python programming language. That will make it more difficult for people to help you, since we may not be communicating using the same vocabulary. A few things you should know:... 1) this (Python-win32) is not a group for the discussion of Python (in general) on Windows platforms. It is for discussion of a specific toolkit (pywin32) which aids programmers in using Python to perform detailed Windows tasks. Your problem has nothing to do with pywin32. (At least, I think not.) 2) someone from the Blender group may be able to provide more help -- but perhaps not, because your problem is not really with Blender either. 3) The software installation which you are attempting to run is very complex. A hundred different things could be wrong. I have access to an old Windows 7 computer which has never had Python installed and I will try to see if I can duplicate your problem. This may take me a day or two. I will contact you directly (not through the group) when I have more information. You could help by letting me know what exactly you mean by: "I just set the var path". -- Vernon Cole On Fri, Dec 25, 2015 at 9:47 AM, Erick Blender wrote: > Hi there, first time, here I m on windows 7 i m trying to build a manual > (http://blender.org/manual/about/install/windows.html) when i run > C:\Python34\Scripts\pip install -r requirements.txt in the cmd, > The cmd hangs and doesn't respond. I just set the var path, can i get some > help? > > _______________________________________________ > python-win32 mailing list > python-win32 at python.org > https://mail.python.org/mailman/listinfo/python-win32 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eryksun at gmail.com Sat Dec 26 13:01:47 2015 From: eryksun at gmail.com (eryk sun) Date: Sat, 26 Dec 2015 12:01:47 -0600 Subject: [python-win32] python-win32 is for Python on Windows Message-ID: On Sat, Dec 26, 2015 at 10:44 AM, Vernon D. Cole wrote: > > 1) this (Python-win32) is not a group for the discussion of Python (in > general) on Windows platforms. It is for discussion of a specific toolkit > (pywin32) Actually, that's not right: python-win32 -- Python on Windows (32-bit and 64-bit) About python-win32: All issues related to programming Python on Windows. 32-bit and 64-bit, pywin32 extensions, COM, you name it. There was some discussion a bit ago about changing the list name to "python-windows", because "win32" is a legacy name. (Microsoft changed the API name to "Windows" a while ago.) The discussion resulted in changing the list title from "Python on win32" [1] to "Python on Windows (32-bit and 64-bit)". [1]: https://web.archive.org/web/20150905161144/https://mail.python.org/mailman/listinfo/python-win32 From mc at mclaveau Sun Dec 27 11:29:59 2015 From: mc at mclaveau (mc at mclaveau) Date: Sun, 27 Dec 2015 17:29:59 +0100 Subject: [python-win32] python-win32 is for Python on Windows In-Reply-To: References: Message-ID: <56801207.8050903@mclaveau.com> Hi! Is "PyWin32" a possible name? @-salutations -- Michel Claveau Le 26.12.15 19:01, eryk sun a ?crit : > On Sat, Dec 26, 2015 at 10:44 AM, Vernon D. Cole wrote: >> 1) this (Python-win32) is not a group for the discussion of Python (in >> general) on Windows platforms. It is for discussion of a specific toolkit >> (pywin32) > Actually, that's not right: > > python-win32 -- Python on Windows (32-bit and 64-bit) > > About python-win32: > All issues related to programming Python on Windows. 32-bit and 64-bit, > pywin32 extensions, COM, you name it. > > There was some discussion a bit ago about changing the list name to > "python-windows", because "win32" is a legacy name. (Microsoft changed > the API name to "Windows" a while ago.) The discussion resulted in > changing the list title from "Python on win32" [1] to "Python on > Windows (32-bit and 64-bit)". > > [1]: https://web.archive.org/web/20150905161144/https://mail.python.org/mailman/listinfo/python-win32 > _______________________________________________ > python-win32 mailing list > python-win32 at python.org > https://mail.python.org/mailman/listinfo/python-win32 > > From rays at blue-cove.com Sun Dec 27 13:33:41 2015 From: rays at blue-cove.com (R Schumacher) Date: Sun, 27 Dec 2015 10:33:41 -0800 Subject: [python-win32] python-win32 is for Python on Windows In-Reply-To: <56801207.8050903@mclaveau.com> References: <56801207.8050903@mclaveau.com> Message-ID: <201512271833.tBRIXkqX019665@blue-cove.com> I think part of the problem is "32" is now antiquated. At 08:29 AM 12/27/2015, mc at mclaveau wrote: >Hi! > >Is "PyWin32" a possible name? > >@-salutations >-- >Michel Claveau > > > >Le 26.12.15 19:01, eryk sun a ?crit : >>On Sat, Dec 26, 2015 at 10:44 AM, Vernon D. >>Cole wrote: >>>1) this (Python-win32) is not a group for the discussion of Python (in >>>general) on Windows platforms. It is for discussion of a specific toolkit >>>(pywin32) >>Actually, that's not right: >> >> python-win32 -- Python on Windows (32-bit and 64-bit) >> >> About python-win32: >> All issues related to programming Python on Windows. 32-bit and 64-bit, >> pywin32 extensions, COM, you name it. >> >>There was some discussion a bit ago about changing the list name to >>"python-windows", because "win32" is a legacy name. (Microsoft changed >>the API name to "Windows" a while ago.) The discussion resulted in >>changing the list title from "Python on win32" [1] to "Python on >>Windows (32-bit and 64-bit)". >> >>[1]: >>https://web.archive.org/web/20150905161144/https://mail.python.org/mailman/listinfo/python-win32 >>_______________________________________________ >>python-win32 mailing list >>python-win32 at python.org >>https://mail.python.org/mailman/listinfo/python-win32 >> > > >_______________________________________________ >python-win32 mailing list >python-win32 at python.org >https://mail.python.org/mailman/listinfo/python-win32 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at timgolden.me.uk Sun Dec 27 16:30:22 2015 From: mail at timgolden.me.uk (Tim Golden) Date: Sun, 27 Dec 2015 21:30:22 +0000 Subject: [python-win32] python-win32 is for Python on Windows In-Reply-To: <201512271833.tBRIXkqX019665@blue-cove.com> References: <56801207.8050903@mclaveau.com> <201512271833.tBRIXkqX019665@blue-cove.com> Message-ID: <5680586E.9050509@timgolden.me.uk> The problem here is that changing the name (as opposed to the description) would break all sorts of existing links. Frankly, I doubt if anyone's actually stopping short of posting to the list merely over a doubt as to whether they can ask about 64-bit issues! TJG On 27/12/2015 18:33, R Schumacher wrote: > I think part of the problem is "32" is now antiquated. > > > At 08:29 AM 12/27/2015, mc at mclaveau wrote: >> Hi! >> >> Is "PyWin32" a possible name? >> >> @-salutations >> -- >> Michel Claveau >> >> >> >> Le 26.12.15 19:01, eryk sun a ?crit : >>> On Sat, Dec 26, 2015 at 10:44 AM, Vernon D. Cole >>> wrote: >>>> 1) this (Python-win32) is not a group for the discussion of Python (in >>>> general) on Windows platforms. It is for discussion of a specific >>>> toolkit >>>> (pywin32) >>> Actually, that's not right: >>> >>> python-win32 -- Python on Windows (32-bit and 64-bit) >>> >>> About python-win32: >>> All issues related to programming Python on Windows. 32-bit and >>> 64-bit, >>> pywin32 extensions, COM, you name it. >>> >>> There was some discussion a bit ago about changing the list name to >>> "python-windows", because "win32" is a legacy name. (Microsoft changed >>> the API name to "Windows" a while ago.) The discussion resulted in >>> changing the list title from "Python on win32" [1] to "Python on >>> Windows (32-bit and 64-bit)". >>> >>> [1]: >>> https://web.archive.org/web/20150905161144/https://mail.python.org/mailman/listinfo/python-win32 >>> >>> _______________________________________________ >>> python-win32 mailing list >>> python-win32 at python.org >>> https://mail.python.org/mailman/listinfo/python-win32 >>> >> >> >> _______________________________________________ >> python-win32 mailing list >> python-win32 at python.org >> https://mail.python.org/mailman/listinfo/python-win32 > > > _______________________________________________ > python-win32 mailing list > python-win32 at python.org > https://mail.python.org/mailman/listinfo/python-win32 > From timr at probo.com Mon Dec 28 14:39:49 2015 From: timr at probo.com (Tim Roberts) Date: Mon, 28 Dec 2015 11:39:49 -0800 Subject: [python-win32] Excel to python COM not working. Please help! In-Reply-To: References: Message-ID: <56819005.2030703@probo.com> Tarun Kapoor wrote: > I am supporting this old legacy code that someone else wrote. A user > had their computer replaced and the code stopped working. We have some > code written in python that we want to access from Excel. We register > the python COM like shown below > ... > Just for the sake of testing, I have these 2 lines of code behind a > button in Excel > > Dim dbServer As Variant > Set dbServer = CreateObject("WSdbAccess") > > And i get the error ""The specified module could not be found" on the > second line of the code. It does work from all other computers. The > environment is Windows 7 64 bit computers with 32 bit excel and 32 bit > python 2.7. I have opened the registry and WSdbAccess does exist. I > have compared the registry of the new computer with the old computers > and its the same.. Where did you look in the registry? Remember that, on a 64-bit system, 32-bit components get registered in HKEY_CLASSES_ROOT\Wow6432Node\CLSID, not in HKEY_CLASSES_ROOT\CLSID. -- Tim Roberts, timr at probo.com Providenza & Boekelheide, Inc. From poseidon-mares at hotmail.com Wed Dec 30 18:02:54 2015 From: poseidon-mares at hotmail.com (David Bernal Michelena) Date: Wed, 30 Dec 2015 17:02:54 -0600 Subject: [python-win32] =?cp1256?q?Help_required_with_407_error_authentica?= =?cp1256?q?tion_using_defaultcredentials=FE?= Message-ID: Hello, I need to be able to have python authenticate with the proxy in an enterprise environment using the credentials of the currently logged on user (NTLM). Since we are using an in house developed application, the program must run on several endpoint computers so it should not require to receive any password. Can anyone please share how to do it? I have done a small program in powershell that is able to demostrate what I need, this program will automatically identify the proxy and if configured will use the defaultcredentials from the current session to authenticate, download the url and print the result.$url="https://weather.yahoo.com/"$proxy = [System.Net.WebRequest]::GetSystemWebProxy()$proxy.Credentials = [System.Net.CredentialCache]::DefaultCredentials$wc = new-object system.net.webclient$wc.proxy = $proxy$wc.downloadString($url) Thanks in advance. David -------------- next part -------------- An HTML attachment was scrubbed... URL: