[issue44078] Output relative path when using PurePath.relative_to
New submission from Mark Hammond :
Comparing two paths, PurePath.relative_to fails with ValueError if the second
path is not in the first.
>>> Path('/a/b').relative_to('/a/b/c')
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python3.9/pathlib.py", line 928, in relative_to
raise ValueError("{!r} is not in the subpath of {!r}"
ValueError: '/a/b' is not in the subpath of '/a/b/c' OR one path is relative
and the other is absolute.
Please extend PurePath.relative_to so it is able to output a relative path in
form of '..' instead of an error. Currently, the only way to do this is to use
relpath from os.path but it would be very useful if Path was able to output the
relative path.
--
components: Library (Lib)
messages: 393262
nosy: mhammondr
priority: normal
severity: normal
status: open
title: Output relative path when using PurePath.relative_to
type: enhancement
versions: Python 3.9
___
Python tracker
<https://bugs.python.org/issue44078>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41771] bdist_wininst doesn't execute postinstall script
Change by Mark Hammond : -- keywords: +patch pull_requests: +21265 stage: -> patch review pull_request: https://github.com/python/cpython/pull/22210 ___ Python tracker <https://bugs.python.org/issue41771> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41771] bdist_wininst doesn't execute postinstall script
New submission from Mark Hammond : install.c tries to dynamically load PyCFunction_New at https://github.com/python/cpython/blob/fb2718720346c8c7a0ad2d7477f20e9a5524ea0c/PC/bdist_wininst/install.c#L686 - however, since 3.8 this no longer exists - PyCFunction_New is a #define which calls PyCFunction_NewEx -- assignee: mhammond messages: 376771 nosy: mhammond priority: normal severity: normal status: open title: bdist_wininst doesn't execute postinstall script type: behavior versions: Python 3.10, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue41771> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41526] Python 3.9.0rc1 "setup successful" dialog box overflow
Mark Hammond added the comment: Yes, while I appreciate the gesture, I am somewhat embarrassed these days - as you say, many others deserve this more than me these days. So please remove it. -- ___ Python tracker <https://bugs.python.org/issue41526> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40740] Missing api-ms-win-core-path-l1-1.0.dll for python-3.9.0b1-amd64.exe Under Win7
Mark Hammond added the comment: Can we get this mentioned somewhere? Eg, https://www.python.org/downloads/release/python-390b3/ doesn't mention anything about minimum versions. https://www.python.org/downloads/windows/ also has prominent notices like "Note that Python 3.8.3rc1 cannot be used on Windows XP or earlier." but nothing for 3.9 (This threw me for some time - I still have a win7 VM I used for testing and figured there was something broken in the VM before finding this) -- nosy: +mhammond ___ Python tracker <https://bugs.python.org/issue40740> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39631] Fix file association MIME type on Windows
Change by Mark Hammond : -- nosy: +mhammond ___ Python tracker <https://bugs.python.org/issue39631> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33944] Deprecate and remove pth files
Mark Hammond added the comment:
pywin32, up until recently, just listed 3 directories in its .pth file - these
were for directories which pre-dated packages and were never converted. Eg,
"import win32api" actually loads win32api.pyd from the "site-packages/win32"
directory.
Earlier this year, via https://github.com/mhammond/pywin32/issues/1151, I also
added the line:
import os;os.environ["PATH"]+=(';'+os.path.join(sitedir,"pywin32_system32"))
which is to support pywin32 being installed from wheels - this is due to
pywin32 shipping with various shared DLLs which implement many pywin32 types -
eg, pywintypesXX.dll is used by (almost) every single .pyd shipped with
pywin32, and disutils doesn't offer any way of copying files as part of a
post-install script or any other way of ensuring these .dll files are on the
PATH or otherwise next to pythonXX.dll/.exe
I'm happy to replace both of these with alternatives when they exist.
--
___
Python tracker
<https://bugs.python.org/issue33944>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27966] PEP-397 documents incorrect registry path
New submission from Mark Hammond: Received via email: PEP-397 (PEP 397 -- Python launcher for Windows) says: """ The launcher installation is registered in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\CurrentVersion\SharedDLLs with a reference counter. """ There is no such entry. It should be HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SharedDLLs -- assignee: docs@python components: Documentation messages: 274525 nosy: docs@python, mhammond priority: normal severity: normal status: open title: PEP-397 documents incorrect registry path ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27966> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27410] DLL hijacking vulnerability in Python 3.5.2 installer
Mark Hammond added the comment: While I agree the risk is fairly low and it will require effort to actually do, it still sounds worth fixing at some point. A user might be tricked into downloading a DLL - eg, Firefox will happily save it without any scary UI - it's just a file. Later they run our "trusted" download from the same directory and we screw them - even if the attacker can't elevate they can do damage. -- nosy: +mhammond ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27410> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27417] Call CoInitializeEx on startup
Mark Hammond added the comment: > > This may well break things like pythonwin until they also grow support > > for the new param > I expect that, which is why I'm only proposing it for 3.6 onwards. While > adding support for a new major version of Python should be fairly cheap, > it isn't entirely free and so it's the right time to add new complications. My point with that is that pythonwin is a GUI app rarely started by the command-line. It isn't that adding the cmdline support is difficult, more that it's difficult for users to specify it. This will be true for any GUI installed into the start menu (eg, idle) > Nikita: > > COM should be initialized on demand by C modules that need it. They might > > need STA or > > MTA, it's their choice to make. > And if the C module is the core interpreter (see issue26137 for an example of > where > this would be necessary)? If we require user code to initialize COM, this > whole > proposal is moot as that is the current state of the world and it does not > require > any changes to achieve. I'd be surprised if issue26137 ended up unconditionally doing a malware scan on everything Python ever executes. Thus, I don't see why "I'd like to enable calling CoInitializeEx on Python startup for 3.6" is necessary - just attempting to initialize it immediately before that feature is invoked would be fine and may sidestep the entire issue. Instead of command-line flags to control COM initialization we should add new flags to disable these new features that require COM (and thus also implicitly control whether COM is initialized or not.) IOW, I think it makes sense for the core to initialize COM immediately before it needs to use COM, under the assumption that executing "python" or "python myscript.py" isn't going to need to do that by default. I think initializing COM by default at process startup on the off-chance that some COM-using feature will be invoked is more problematic. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27417> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27417] Call CoInitializeEx on startup
Mark Hammond added the comment: I've a few reservations here: * CoInitialize will load a number of COM DLLs into the process, which isn't free and will have some memory and performance costs for programs that don't use COM. I see around 10 such DLLs loaded. * pythoncom uses sys.coinit_flags because some COM objects simply don't work with the wrong apartment model. IOW, it is the objects you want to use on a particular thread that dictates the model you should use for that thread. Thus scripts written to interact with a particular COM object could set this flag before importing pythoncom so the correct threading model is setup. If this is done at Python startup, the script has lost the chance to influence this - insisting that Python be run with a particular set of flags for the script to work sounds painful. * pythoncom defaults to COINIT_APARTMENTTHREADED as the apartment threading model is a special snowflake - if you need to use apartment model objects, the main thread *must* be apartment threading (even though other threads can use free threading.) COM objects with a UI (eg, MSOffice, IE) typically required apartment threading. Most new objects probably allow free threading, but I think we want to be careful about defaulting to a model that might avoid common objects from being used without an obscure command-line param. * This may well break things like pythonwin until they also grow support for the new param - but new params for GUI applications somewhat suck as people tend to start them from an icon instead of the command-line. * Each thread that wants to use COM must also make this call. If *any* object you want to use uses apartment model threading, then you really have no choice other than to init the main thread with this model - but you are then free to spin up other threads using free-threading, and life is good. So to make this sane, you really want to expose CoInitialize to Python code so new threads can do the right thing. So in this case, I wonder why we don't just expose it and let it be called manually? IOW, it seems the potential risks of this outweighs the cost of requiring it to be called manually in a controlled way. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27417> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26071] bdist_wininst created binaries fail to start and find 32bit Pythons
Mark Hammond added the comment: > Mark said the "built binary links against the DLL version of the CRT > but I just checked in 3.5.1 that you actually didn't switch that > one to link against vcruntime140.dll like you did with everything else Yeah, I didn't dig too much further here, but I'm fairly sure that "static crt" has been a thing for quite a while now for that stub (there are comments about that around the SetStdHandle calls in that file). I suspect it was accidentally lost in one of the build system fixups that happened (which seem great and a vast improvement!) -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26071> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26071] bdist_wininst created binaries fail to start and find 32bit Pythons
New submission from Mark Hammond: Binaries created by bdist_wininst fail on 3.5+ for 2 reasons: * The built binary links against the DLL version of the CRT. This means the binary will typically fail to start as the CRT DLL isn't found. * When looking for 32bit Python versions, it fails to take the recent "-32" change for the registry key, so it tells you no Python is installed. This patch: * Uses the static CRT, which IIRC, was the case in previous Python versions. * Changes directory to the directory with pythonxx.dll before attempting to loadlibrary it - this allows the loadlibrary to succeed as the CRT DLL in that directory is found. * Appends "-32" to registry keys on 32bit builds. With these patches I can successfully get a pywin32 build working and installing. Steve (or anyone), what do you think? (Note that the attached patch does *not* include a newly built wininst-14.exe, but that would obviously need to be updated before checking in.) -- components: Windows files: bdist.patch keywords: patch messages: 257879 nosy: mhammond, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: bdist_wininst created binaries fail to start and find 32bit Pythons type: behavior versions: Python 3.5, Python 3.6 Added file: http://bugs.python.org/file41561/bdist.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26071> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26070] Launcher fails to find in-place built binaries from earlier Python versions
New submission from Mark Hammond: The launcher was recently updated to look in PCBuild/win32 to support the win32 binaries being built in this directory instead of the top-level PCBuild directory. However, when this new launcher tries to find a binary for, say, Python 2.7, it doesn't find an executable because it's directly in PCBuild, not one of the win32 or amd64 sub-directories. Note this only impacts Python when it is built in the directory - it doesn't impact installed versions. The fix I came up with is to continue looking in PCBuild if it isn't found in one of those dirs. Vinay, what do you think? -- components: Windows files: launcher.patch keywords: patch messages: 257878 nosy: mhammond, paul.moore, steve.dower, tim.golden, vinay.sajip, zach.ware priority: normal severity: normal status: open title: Launcher fails to find in-place built binaries from earlier Python versions type: behavior versions: Python 3.5, Python 3.6 Added file: http://bugs.python.org/file41560/launcher.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26070> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26070] Launcher fails to find in-place built binaries from earlier Python versions
Mark Hammond added the comment: > When is the launcher ever going to find Python built in-place? On the machine that built Python in-place :) I have a dev environment where all Python versions and pywin32 are built and that's the environment where py.exe is failing. My build scripts use py.exe to build for a specific Python version. It sounds like you are fine with it, so I'll try and work out how to get a new key up and push it unless I hear otherwise, thanks. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26070> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25148] Windows registry PythonCore key changed inconsistent with other releases
Mark Hammond added the comment: It appears bdist_wininst wasn't updated for this so installed created by distutils don't work in 32bit versions - is there a different bug open for that? (Or I'm doing something wrong, but the installer fails and a quick scan of the source doesn't seem to handle it) -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25148> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25921] project files for wininst-14.0*.exe don't exist
Mark Hammond added the comment: Awesome, thanks, sorry I missed that. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25921> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25921] project files for wininst-14.0*.exe don't exist
New submission from Mark Hammond: Revision 34b35aa1967d pushed new versions of wininst-14.8*.exe, but didn't include the VS project files required to build it, thus meaning it can't reasonably be built from the source tree. -- components: Build messages: 256823 nosy: mhammond, steve.dower priority: normal severity: normal status: open title: project files for wininst-14.0*.exe don't exist ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25921> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25148] Windows registry PythonCore key changed inconsistent with other releases
Mark Hammond added the comment: > and the launcher was actually updated to match the registry key > directly, rather than special-casing the "-32" suffix It appears this has broken the launcher. A freshly-built py.exe from Python 3.5 doesn't seem to find older 32bit versions, while py.exe from older versions doesn't find the 32bit 3.5. Doesn't this break the entire reason for having the launcher in the first place? -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25148> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25148] Windows registry PythonCore key changed inconsistent with other releases
Mark Hammond added the comment:
> The original naming ("3.5") can't be used because you can't
> simultaneously install 32-bit and 64-bit per-user Pythons with the same
> key name.
They will be in different nodes - the 32bit version would be under Wow6432Node.
The py.exe launcher had no issues locating 64 and 32 bit versions, so I don't
understand any of the justifications here. I believe this change is most
certainly a bug and will break many tools that looked in the registry for
Python using the sane approach used previously.
--
nosy: +mhammond
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue25148>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1602] windows console doesn't print or input Unicode
Mark Hammond added the comment: File redirection has nothing to do with win-unicode-console Thank you, that comment is spot on - there are multiple issues being conflated here. This bug is purely about the tty/console behaviour. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1602 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1602] windows console doesn't print or input Unicode
Mark Hammond added the comment: The crash you see is maybe not a crash at all. I'd call it a crash - the repl shouldn't exit. But it's not necessarily part of *this* bug. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1602 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21354] PyCFunction_New no longer exposed by python DLL breaking bdist_wininst installers
New submission from Mark Hammond: Python 3.3 and earlier have in methodobject.c: /* PyCFunction_New() is now just a macro that calls PyCFunction_NewEx(), but it's part of the API so we need to keep a function around that existing C extensions can call. */ #undef PyCFunction_New PyAPI_FUNC(PyObject *) PyCFunction_New(PyMethodDef *, PyObject *); which means PyCFunction_New is exported from the DLL. Python 3.4 does not have this (which seems a bug in its own right given the comment in 3.3 and earlier) but PC/bdist_wininst/install.c has code that attempts to dynamically load this function from the DLL and fails, causing 3rd party installers to fail. Assuming the removal of this API was intentional so the problem is that install.c needs to be updated, the following patch fixes the issue. -- components: Windows files: t.patch keywords: patch messages: 217185 nosy: mhammond priority: normal severity: normal status: open title: PyCFunction_New no longer exposed by python DLL breaking bdist_wininst installers type: behavior Added file: http://bugs.python.org/file35043/t.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21354 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14302] Rename Scripts directory to bin and move python.exe to bin
Mark Hammond added the comment: I get the impression the first link just punted and the second supports the fact many people would see it as an improvement. So a patch that both works and addresses the concerns would probably be most welcome! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14302 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19141] Windows Launcher fails to respect PATH
Mark Hammond added the comment: I am trying to draw attention to the situation where the script has no shebang line, and there is no other explicit configuration info for py.exe. In that case, the user should just type python scriptname.py - py.exe is for cases where just specifying python doesn't do the right thing. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19141 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18491] Add exe wrapper functionality to Windows launcher
Mark Hammond added the comment: Vinay's idea makes sense to me. Paul can also subtly change the patch such that when SCRIPT_WRAPPER is defined, failure to find the wrapper is fatal and prints a message specific to this fact rather than just starting an interactive Python (assuming I read the patch correctly, that is :) Then a new .exe is built named something innocuous, installed in a single well-known location as the stub and that pip-style code creating the wrapper has a nice easy job :) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18491 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18491] Add exe wrapper functionality to Windows launcher
Mark Hammond added the comment: I don't understand the motivation for this - how will it be used in practice? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18491 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18491] Add exe wrapper functionality to Windows launcher
Mark Hammond added the comment: Obviously I'm missing a little context, but it seems a little wrong for the same launcher to be doing this double-duty. It seems we only want to use the launcher in this way as it already has some of the interesting code we need - but the vast majority of users aren't going to want to have it behave this way implicitly (ie, when they start what they consider the launcher, they aren't going to expect this magic. Conversely, when someone executes foo, they are going to be expecting exactly 1 thing to happen and that isn't do what py.exe with no args does) So maybe this could be behind a #define, and have another .exe built from the same sources? One exe sticks with the launcher semantics (ie, never looks for foo-script.py), and the other sticks with the wrapper semantics (ie, terminates with an error if foo-script.py can't be found) All that said though, I'm not involved in the distutils discussions and acknowledge the general requirements as real, so do whatever you need to do :) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18491 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17290] pythonw - loading cursor bug when launching scripts
Mark Hammond added the comment: The problem is that Explorer displays the IDC_APPSTARTING icon when an app launches, until that app does something ui-ish (eg, creating a window, fetching a windows message). I could reproduce the problem on XP, and pushed a fix for the launcher to https://bitbucket.org/vinay.sajip/pylauncher/commits/639582f0bebbabbf63fe8746986122173e765baf which solves the problem for me. I'm not sure what the process is for getting that fix into the Python repo - hopefully Vinay knows :) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17290 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17290] pythonw - loading cursor bug when launching scripts
Mark Hammond added the comment: If anyone would like to test the fix out, I've put a 32bit pyw.exe with the fix at http://starship.python.net/crew/skippy/downloads/pyw.exe -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17290 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: accessing an OLE Automation (IDispatch) server from python which requires the use of out params
On 12/12/2012 2:48 AM, bitbucket wrote: On Monday, December 10, 2012 8:16:43 PM UTC-5, Mark Hammond wrote: out params are best supported if the object supplied a typelib - then Python knows the params are out and does the right thing automagically. If out params are detected, the result of the function will be a tuple of (real_result, out_param1, ...) Even if no typelib is supported, you can access them with a little pain via the win32com.client.Dispatch() object. You might like to follow up to the python-wi...@python.org mailing list where many people will be able to help. HTH, Mark Mark, thanks for the reply. In this case, I have a type library and attempted to use MakePy but it doesn't seem to be working as expected. I was reading through CH12 of your Python Programming on Win32 book (http://oreilly.com/catalog/pythonwin32/chapter/ch12.html). I was hopeful given your description of MakePy that I could get this to work. It appears that you're saying MakePy will convert byref args in a function over to return values. For example, the IDL in the server includes the following 3 functions. [id(1)] void ShowMessage(BSTR msg); [id(2)] void GetSettingValue(BSTR settingName, BSTR* settingValue); [id(3)] void SetSettingValue(BSTR settingName, BSTR settingValue); The thorny one is the GetSettingValue since it takes the out param. When I run MakePy, it generates the below. def ShowMessage(self, msg=defaultNamedNotOptArg): return self._oleobj_.InvokeTypes(1, LCID, 1, (24, 0), ((8, 0),),msg ) def GetSettingValue(self, settingName=defaultNamedNotOptArg, settingValue=defaultNamedNotOptArg): return self._oleobj_.InvokeTypes(2, LCID, 1, (24, 0), ((8, 0), (16392, 0)),settingName , settingValue) def SetSettingValue(self, settingName=defaultNamedNotOptArg, settingValue=defaultNamedNotOptArg): return self._oleobj_.InvokeTypes(3, LCID, 1, (24, 0), ((8, 0), (8, 0)),settingName , settingValue) I noticed that the argument type is different for the out param (16392 instead of 8). However, it doesn't appear to me that its generating return values instead of args (though I'm not very experienced in python). I tried invoking these in python. The ShowMessage and SetSettingValue work great. I can't get the GetSettingValue to work though. Perhaps there's a different syntax I need when using the MakePy generated code? Seeing the real return value is void, it should just be a matter of: settingValue = ob.GetSettingValue(settingName) Mark -- http://mail.python.org/mailman/listinfo/python-list
Re: accessing an OLE Automation (IDispatch) server from python which requires the use of out params
On 11/12/2012 8:39 AM, bitbucket wrote: On Monday, December 10, 2012 3:58:33 PM UTC-5, Terry Reedy wrote: I believe the easiest way to do that is to install the pywin extensions http://sourceforge.net/projects/pywin32/?source=directory I assume it can handle out params. That definitely looks like a good starting point. Just hoping someone knows whether or not it'll support the out params before I spend too much time digging into it. out params are best supported if the object supplied a typelib - then Python knows the params are out and does the right thing automagically. If out params are detected, the result of the function will be a tuple of (real_result, out_param1, ...) Even if no typelib is supported, you can access them with a little pain via the win32com.client.Dispatch() object. You might like to follow up to the python-wi...@python.org mailing list where many people will be able to help. HTH, Mark -- http://mail.python.org/mailman/listinfo/python-list
Re: Why is pylaucher in Python 3.3 being installed in Windows folder?
On 5/10/2012 2:40 AM, Oscar Benjamin wrote: Having them on PATH means that you can do: py script.py and the effect will be analogous to (in a unix shell): $ ./script.py Of course the idea with the launcher is that you just do script.py Unless you want a specific version - particularly for testing - eg: % py -3.2 script.py Mark -- http://mail.python.org/mailman/listinfo/python-list
[issue15751] Support subinterpreters in the GIL state API
Mark Hammond added the comment: The GIL state api was mainly interested in the case of a thread which has (possibly) never been seen before calling into Python. IIUC, the proposal here is so that a thread that *has* been seen before can be associated with a thread-state specified by the embedding application (and the degenerate case would be to assume the thread hasn't been seen, and as such should get the default interpreter) If that isn't too wide of the mark, I agree it sounds workable and worthwhile. -- nosy: +mhammond ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15751 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15751] Support subinterpreters in the GIL state API
Mark Hammond added the comment: To clarify, I wrote: can be associated with a thread-state specified by the embedding application Where I meant to say: Can be associated with an interpreter state and corresponding thread-state ... Or something like that - it's been a while since I've looked at that code. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15751 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Legal: Introduction to Programming App
Your only concern from the Python world will (probably; IANAL) be around use of trademarks owned by the PSF - see http://www.python.org/psf/trademarks/ for more. Mark On 20/08/2012 12:13 PM, Matthew Zipf wrote: Good evening, I am considering developing an iOS application that would teach average people how to program in Python. The app will be sold on the Apple app store. May I develop this app? To what extent do I need to receive permission from the Python Software Foundation? To what extent do I need to recognize the Python Software Foundation in my app? Thank you, Matthew Zipf -- http://mail.python.org/mailman/listinfo/python-list
Re: missing python-config and building python on Windows
On 1/08/2012 10:48 AM, Damon Register wrote: I am attempting to build gtk and glade using mingw/msys. It seems that some of the packages require python. I installed 2.7.3 using the installer from python.org. That worked for some of the packages but now I am trying to do one that needs python-config which I don't find in the installation directory. I tried building from source using mingw/msys but that had too many problems so I gave up on that. I thought I might try building with MSVC 2010 since it appears to be supported and I have that at work. There are a few problems with this: 1. though I have looked in a few readme files, I don't see instructions for installing what I have just built using MSVC. Where can I find the instructions for installing after building with MSVC? There is no such process. In general, you can just run directly from the built tree. 2. I have searched the project directory but I don't find python-config. Is this some sort of optional thing that isn't built by default? I tried searching this list and although I find a few questions about it, I don't see an answer to where I can find it. I'm afraid I don't know what python-config is. It appears it might be a reflection of how Python was configured and build on *nix systems - if that is the case then it is expected that one does not exist for Windows (as it doesn't use the *nix build chain). 3. It seems that MSVC doesn't produce the .a library files needed for linking into a mingw built program. Do I have to do that fun trick to create the .a from the dll? I'm surprised MSVC *can* build .a files for mingw - but AFAIK, even if MSVC could do that, I believe Python makes no attempt to build with support for linking into mingw programs. Mark -- http://mail.python.org/mailman/listinfo/python-list
[issue15321] bdist_wininst installers may terminate with close failed in file object destructor:\nsys.excepthook is missing\nlost sys.stderr
New submission from Mark Hammond skippy.hamm...@gmail.com: Note the error message in the title is only for Python 2.x - Python 3.x shows an empty string instead, but otherwise seems identical. This was first brought to my attention via http://sourceforge.net/tracker/?func=detailaid=352group_id=78018atid=551954. I can reproduce it (see below) with the pywin32 installer but believe the problem will exist with any such installer. All tests done on a Win7x64 VM. Symptoms are: * Run the installer with UAC enabled - reliably works. All print statements from the post-install script are shown in the final dialog. * Disable UAC. The installation reliably ends with the close failed... message shown in the final dialog. No print output is shown. The installation did actually complete (but is likely to fail if the output fills stdout buffering). The UAC is probably relevant as when UAC is enabled, the installer re-spawns itself with elevation. * The problem with UAC disabled can be reproduced running in the VS debugger. The problem is that Python sees stdout and stderr with a FILE object that has a fileno of -2 (ie, of _NO_CONSOLE_FILENO). Then, when Python is finalizing it tries to close these handles and fails due to the invalid fileno. The other messages are a consequence of the fact stderr itself is what is being closed (ie, Python is trying to report a problem closing stderr to stderr.) Python 3 seems to handle this case better courtesy of issue 1415, but the fact the output is lost remains in both versions. * Looking over the installer code, I notice that Python is initialized and terminated twice to compile .pyc/.pyo, then initialized a third time in preparation to run the install script - the handles are redirected prior to initializing the 3rd time. On a hunch, I hacked the code to perform the redirection *before* Python is initialized for the first time. This solved the problem when run under the debugger but still failed when run stand-alone (*sigh*). I fiddled with some params to CreateFile in the redirection code but could not get things working. Note that avoiding the multiple init/finalize calls may be problematic as Py_OptimizeFlag is set differently between runs. * I looked over the CRT init code to try and determine why _NO_CONSOLE_FILENO was being used. It appears the CRT attempts to use the process STARTUPINFO and only falls back to GetStdHandle if that STARTUPINFO doesn't provide valid handles. So I tried both using GetStartupInfo and putting the redirect handles in the result, and explicitly closing the old std handles, but neither of them worked. Next step is probably to arrange to step through the CRT init code to see what is going on there. I doubt I will get back to this any time soon, so this is my attempt at detailing what I've discovered to date incase someone else has a look... -- assignee: eric.araujo components: Distutils messages: 165213 nosy: eric.araujo, mhammond, tarek priority: normal severity: normal status: open title: bdist_wininst installers may terminate with close failed in file object destructor:\nsys.excepthook is missing\nlost sys.stderr type: behavior versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15321 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: exe made by py2exe do not run certain computer
On 4/07/2012 9:46 AM, Miki Tebeka wrote: It works fine on my computer and some other computer don't have python interpreter(it's Windows 7). But the same file also do not work on another computer(it's Windows xp) why does it happen? My *guess* is that you're missing some DLLs (probably some Visual Studio runtime ones). You can run http://www.dependencywalker.com/ on the generated exe and see which DLLs it uses. If you do it on the machine with the problems, these DLLs will be highlighted. Another possibility is that py2exe is erroneously picking up *other* DLLs from the OS, which you are packaging and installing. So check your distribution for *all* .dll files - most Python extension modules are .pyd, so the actual number of .dll files needed should be quite small and relatively stable across different py2exe invocations. Mark -- http://mail.python.org/mailman/listinfo/python-list
Re: changes made to my python coded com servers are not taking effect
On 1/07/2012 7:13 PM, Panceisto wrote: I assume the old code keeps running in some process somewhere. How to fix this? The client of your server still has a reference to the old server. The simplest solution is to restart those clients. Mark -- http://mail.python.org/mailman/listinfo/python-list
[issue1677] Ctrl-C will exit out of Python interpreter in Windows
Changes by Mark Hammond skippy.hamm...@gmail.com: -- nosy: +mhammond ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1677 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: bdist_wininst [was: Custom build of Python]
On 22/06/2012 3:10 AM, KACVINSKY Tom wrote:
I found what I was looking for:
python setup.py bdist_wininst
bdist_wininst is for creating installers for Python packages which
install into an existing Python directory structure. It isn't used to
create a installer for Python itself (which unless I misunderstand,
seems what you are trying to do).
Apart from generating an official MSI like Python itself ships as,
IIUC, there is no other way to take a built tree and create an
installer. On the other hand though, a built tree will generally work
fine if transplanted somewhere else, so long as a couple of registry
entries are created. So you could do something like creating an inno
installer script that takes your built tree and generates a custom
installer for your build.
Mark
But... I follow all of the instructions for building Python on Windows and then
follow the instructions for using bdist_wininst, and I get this:
C:\Users\tky\Python\Python-2.6.8PCbuild\amd64\python.exe setup.py bdist_wininst
running bdist_wininst
running build
running build_ext
INFO: Can't locate Tcl/Tk libs and/or headers
Traceback (most recent call last):
File setup.py, line 2049, in module
main()
File setup.py, line 2044, in main
'Lib/smtpd.py']
File C:\Users\tky\Python\Python-2.6.8\lib\distutils\core.py, line 152, in
setup
dist.run_commands()
File C:\Users\tky\Python\Python-2.6.8\lib\distutils\dist.py, line 975, in
run_commands
self.run_command(cmd)
File C:\Users\tky\Python\Python-2.6.8\lib\distutils\dist.py, line 995, in
run_command
cmd_obj.run()
File
C:\Users\tky\Python\Python-2.6.8\lib\distutils\command\bdist_wininst.py, line
125, in run
self.run_command('build')
File C:\Users\tky\Python\Python-2.6.8\lib\distutils\cmd.py, line 333, in
run_command
self.distribution.run_command(command)
File C:\Users\tky\Python\Python-2.6.8\lib\distutils\dist.py, line 995, in
run_command
cmd_obj.run()
File C:\Users\tky\Python\Python-2.6.8\lib\distutils\command\build.py, line
134, in run
self.run_command(cmd_name)
File C:\Users\tky\Python\Python-2.6.8\lib\distutils\cmd.py, line 333, in
run_command
self.distribution.run_command(command)
File C:\Users\tky\Python\Python-2.6.8\lib\distutils\dist.py, line 995, in
run_command
cmd_obj.run()
File C:\Users\tky\Python\Python-2.6.8\lib\distutils\command\build_ext.py,
line 340, in run
self.build_extensions()
File setup.py, line 167, in build_extensions
raise ValueError(No source directory; cannot proceed.)
ValueError: No source directory; cannot proceed.
Does anyone know of a way to get bdist_wininst to work out of the box? I am
not comfortable with hacking distutils. What do the maintainers do in this
case?
Thanks,
Tom
-Original Message-
From: python-list-bounces+tky=3ds@python.org
[mailto:python-list-bounces+tky=3ds@python.org] On Behalf Of KACVINSKY Tom
Sent: Wednesday, June 20, 2012 4:29 PM
To: python-list@python.org
Subject: RE: Custom build of Python
Terry,
At this stage, I don't want or need an MSI. I just want something that will
bundle the executables/dynamic load libraries + compiled Python files and stick
them into a compliant directory structure.
Regards,
Tom
-Original Message-
From: python-list-bounces+tky=3ds@python.org
[mailto:python-list-bounces+tky=3ds@python.org] On Behalf Of Terry Reedy
Sent: Wednesday, June 20, 2012 4:13 PM
To: python-list@python.org
Subject: Re: Custom build of Python
On 6/20/2012 2:24 PM, KACVINSKY Tom wrote:
I had reason to build Python 2.6.8 with Microsoft Visual Studio 2010.
I was able to get the pcbuild solution to build, and I have the
necessary exes/dlls/pyds in the amd64 build directory. What is not
clear to is how to complete the build and make an installation. I
could not find any documentation for this.
If you mean 'make a .msi file', I am not sure that is not officially supported
beyond the inclusion of msilib.
Any help on this matter would be appreciated.
3.3 is now being built with VS2010. Perhaps its repository has something that
will help you.
--
Terry Jan Reedy
--
http://mail.python.org/mailman/listinfo/python-list
This email and any attachments are intended solely for the use of the
individual or entity to whom it is addressed and may be confidential and/or
privileged.
If you are not one of the named recipients or have received this email in error,
(i) you should not read, disclose, or copy it,
(ii) please notify sender of your receipt by reply email and delete this email
and all attachments,
(iii) Dassault Systemes does not accept or assume any liability or
responsibility for any use of or reliance on this email.
For other languages, go to http://www.3ds.com/terms/email-disclaimer
--
http://mail.python.org/mailman/listinfo/python-list
This email and any attachments are intended solely for the use of the
individual or entity to whom it is
Re: Embedding Python27 in C++ on Windows: CRT compatibility issues with VS2010?
On 25/05/2012 2:10 AM, Stephen Lin wrote: Hello, I'm a relative python newbie but I've been tasked to figure out how to embed calls to a python library in an Excel XLL add-in. The Python/C API for doing this seems pretty straightforward, but I seem to have read somewhere online that it's important that the C++ program or DLL linking to and embedding Python must be using the same CRT as what the Python implementation dll is using. Is this true, or is the Python API written in such a way that there is no dependency on a common CRT? It depends on the APIs you use. eg, some APIs take a FILE * and some may take ownership of memory - such APIs needs to use the same CRT. APIs that don't attempt to share CRT objects should be fine. Mark If there is a dependency, does that mean that I cannot use VS2010 to develop this XLL, but should use VS2008 instead, or are there other workarounds? Thanks for the help, Stephen -- http://mail.python.org/mailman/listinfo/python-list
Re: Compiling debug Python 2.7 on Windows
On 23/05/2012 2:42 AM, Иван Громов wrote: Hi, I'm trying to compile a debug version of Python 2.7 on Windows, but I've encountered some problems while creating a distribution.\ When I run PCbuild\python.exe setup.py bdist_wininst I get an error error: pyconfig.h: No such file or directory As far as I understand, I need to run something similar to ./configure on Linux, but I haven't found any information what the command should be. GnuWin32 autoconf also fails with errors. What is the correct way to build Python distribuiton from source on Windows? I believe the correct way is still to load the PCBuild/PCBuild.sln file as a project in MS Visual Studio 2008. Cheers, Mark -- Best regards, Ivan Gromov -- http://mail.python.org/mailman/listinfo/python-list
Re: Right way to initialize python embedded in a multi-threaded application
On 17/05/2012 10:08 PM, shooshx wrote: I'm embedding python in a multi-threaded C application. I've taken care to wrap every call to the Python C API with gstate = PyGILState_Ensure(); // call python code PyGILState_Release(gstate); But I'm stumped with what to do in the initialization. Right after the call to Py_IsInitialized() I've added a call: PyEval_InitThreads(); The docs say that this function leaves the GIL locked when it returns. I do some more initializations like importing modules and then I call PyEval_ReleaseLock(); This seems to cause a problem since not long after a call to PyGILState_Release(gstate) that's made in a different thread crashes. with Fatal Python error: This thread state must be current when releasing If I don't do the call to PyEval_ReleaseLock() in the main thread right after initialization, the GIL seems to be released after the first PyGILState_Ensure() - PyGILState_Release() pair. So what am I doing wrong here? What is the correct way of initializing a multi-threaded application? Try replacing the PyEval_ReleaseLock() call with PyEval_SaveThread(); - that works for pythoncom, which has the same basic requirement - see http://pywin32.hg.sourceforge.net/hgweb/pywin32/pywin32/raw-file/b8c62cf04c5a/com/win32com/src/dllmain.cpp for how it works. HTH, Mark -- http://mail.python.org/mailman/listinfo/python-list
Re: Generating custom Windows installers
On 7/04/2012 12:57 AM, Cesar Covarrubias wrote: I'm still getting my feet wet on the Windows side of things with Python, so I apologize for the noobish question. If i am reading the create_link.py example correctly, that is created when the application itself is invoked, not during installation. Is that correct? If it is, how would I be able to invoke that when generating the MSI so that the installer creates the shortcut? Right - I think I misunderstood your question. If you can't arrange for install.py to run then what I suggested isn't going to help that. Note however that bdist_msi really isn't targeted at creating stand-alone installations, but instead at installing Python extension modules. I'd recommend using cx_Freeze to create the app, but looking further afield to create the installer for the app (eg, Inno, NSIS, WiX, etc) Mark Cesar On Thu, Apr 5, 2012 at 8:42 PM, Mark Hammond skippy.hamm...@gmail.com mailto:skippy.hamm...@gmail.com wrote: Seeing you are relying on win32com, you might as well add the links directly rather than via the intermediate WScript.shell object. Look in win32comext\shell\demos\__create_link.py for an example of how to create shortcuts directly. HTH, Mark On 6/04/2012 5:23 AM, cesar.covarrub...@gmail.com mailto:cesar.covarrub...@gmail.com wrote: Hello, I am working on creating an installer of a Python 3.2 application that we programmed. The end goal is to create an installer in which we can specify the install path, and create shortcuts in the Start Menu and Desktop. Ideally, we would like to give the users the option to create the Desktop or Start Menu shortcuts. I was able to create a .msi file with the setup.py and install.py files below. This allowed me to specify the custom default path but not create the shortcut in the Start Menu. Can anyone help me figure out what I'm missing? setup.py from cx_Freeze import setup, Executable import sys productName = ProductName if 'bdist_msi' in sys.argv: sys.argv += ['--initial-target-dir', 'C:\InstallDir\\' + productName] sys.argv += ['--install-script', 'install.py'] exe = Executable( script=main.py, base=Win32GUI, targetName=Product.exe ) setup( name=Product.exe, version=1.0, author=Me, description=Copyright 2012, executables=[exe], scripts=[ 'install.py' ] ) --__--- install.py -- import os import sys import win32com.client as w32client shortcut_group_name = Start Menu Dir shortcut_name = Product Name shortcut_target = http://www.microsoft.com; sh = w32client.Dispatch(WScript.__Shell) p = sh.SpecialFolders(__AllUsersPrograms) assert(os.path.isdir(p)) p = os.path.join(p, shortcut_group_name) if (not os.path.isdir(p)): os.makedirs(p) lnk = sh.CreateShortcut(os.path.__join(p, shortcut_name + .lnk)) lnk.TargetPath = shortcut_target lnk.Save() -- Very Respectfully, Cesar Covarrubias -- http://mail.python.org/mailman/listinfo/python-list
Re: Generating custom Windows installers
Seeing you are relying on win32com, you might as well add the links directly rather than via the intermediate WScript.shell object. Look in win32comext\shell\demos\create_link.py for an example of how to create shortcuts directly. HTH, Mark On 6/04/2012 5:23 AM, cesar.covarrub...@gmail.com wrote: Hello, I am working on creating an installer of a Python 3.2 application that we programmed. The end goal is to create an installer in which we can specify the install path, and create shortcuts in the Start Menu and Desktop. Ideally, we would like to give the users the option to create the Desktop or Start Menu shortcuts. I was able to create a .msi file with the setup.py and install.py files below. This allowed me to specify the custom default path but not create the shortcut in the Start Menu. Can anyone help me figure out what I'm missing? setup.py from cx_Freeze import setup, Executable import sys productName = ProductName if 'bdist_msi' in sys.argv: sys.argv += ['--initial-target-dir', 'C:\InstallDir\\' + productName] sys.argv += ['--install-script', 'install.py'] exe = Executable( script=main.py, base=Win32GUI, targetName=Product.exe ) setup( name=Product.exe, version=1.0, author=Me, description=Copyright 2012, executables=[exe], scripts=[ 'install.py' ] ) - install.py -- import os import sys import win32com.client as w32client shortcut_group_name = Start Menu Dir shortcut_name = Product Name shortcut_target = http://www.microsoft.com; sh = w32client.Dispatch(WScript.Shell) p = sh.SpecialFolders(AllUsersPrograms) assert(os.path.isdir(p)) p = os.path.join(p, shortcut_group_name) if (not os.path.isdir(p)): os.makedirs(p) lnk = sh.CreateShortcut(os.path.join(p, shortcut_name + .lnk)) lnk.TargetPath = shortcut_target lnk.Save() -- http://mail.python.org/mailman/listinfo/python-list
Re: OAuth 2.0 implementation
On 28/03/2012 1:18 AM, Roy Smith wrote: In article 7909491.0.1332826232743.JavaMail.geo-discussion-forums@pbim5, Demian Brecht demianbre...@gmail.com wrote: OAuth 2.0 is still in draft status (draft 25 is the current one I believe) and yes, unfortunately every single server available at this point have varying degrees of separation from the actual spec. It's not a pseudo-standard, it's just not observed to the letter. Google is the closest and Facebook seems to be the farthest away (Stack Exchange is in close second due to building theirs to work like Facebook's). In practice, OAuth is all about getting your site to work with Facebook. That is all most web sites care about today because that's where the money is. The fact that other sites also use OAuth is of mostly academic interest at this point. The next player on the list is Twitter, and they're not even up to using their own incompatible version of OAuth 2.0. They're still using OAuth 1.0 (although, I understand, they're marching towards 2.0). Almost all social or sharing sites implement OAuth - either 1.0 or 2.0. Facebook is clearly the big winner here but not the only player. It's also used extensively by google (eg, even their SMTP server supports using OAuth credentials to send email) I'd go even further - most sites which expose an API use OAuth for credentials with that API. Mark -- http://mail.python.org/mailman/listinfo/python-list
[issue14302] Move python.exe to bin/
Mark Hammond skippy.hamm...@gmail.com added the comment: To clarify the second comment from Eric: it is actually the first of the proposals that I consider controversial - moving where python.exe lives (regardless of to where) will break 3rd party tools. If a decision was made to move it anyway, then renaming Scripts to bin and installing it there makes sense IMO. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14302 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14302] Move python.exe to bin/
Mark Hammond skippy.hamm...@gmail.com added the comment: Tools that use the registry will typically look up the InstallPath key and look for python.exe there. They will not look in sub-directories (except some may look in PCBuild and PCBuild/amd64). It is exactly those tools I'm concerned about. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14302 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Python 3.2 and MS Outlook
On Thursday, 8 March 2012 1:52:48 AM, Greg Lindstrom wrote: Is there documentation showing how to read from a Microsoft Outlook server using Python 3.2. I've done it with 2.x, but can't find anything to help me with 3.2. What problems are you having in 3.2? It should be exactly the same - except, obviously, for the general differences between 2 and 3 (ie, any differences should not be due to needing to talk to Outlook and would exist regardless of the job at hand) Mark -- http://mail.python.org/mailman/listinfo/python-list
[issue8170] Wrong Paths for distutils build --plat-name=win-amd64
Mark Hammond skippy.hamm...@gmail.com added the comment: Those instructions in section 5.4 do seem wrong. On first reading they imply that you need to start with a clean source tree on your 32bit Windows, then build the 64bit version of Python. So far so good. However, then you need to run python.exe - which must be a 32bit version of Python or it wouldn't start. So I *guess* the instructions really should say to build *both* the 32 and 64bit versions in the same source tree - in which case I can see why your patch would be necessary. Can you confirm the process you used? I assume you did build both versions in the same tree, but you also mentioned copying the .lib files around - was that an attempt to work around this bug? But yeah, sorry for the distraction - given 5.4 I think this bug is probably valid, but the patch should probably include updated instructions in 5.4 to make it more clear. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8170 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: check if directory is writable in a portable way
On 28/02/2012 9:07 PM, Andrea Crotti wrote: How should I check if I can create files in a directory? By trying to create them there :) Presumably you want to know that so you can write something real - so just write that something real. The problem gets quite hard when you consider things like elevation - your *user* may have rights to write to a directory but only when elevated - think writing into Program Files. Further, this check can only ever be transient - what if you have the rights by virtue of a group membership, but tomorrow you are no longer in that group? Or by virtue of being the owner of the directory but later losing the ownership? The only reasonable way to check is to write to it, and you may as well skip attempting to write a temp file - just write what you care about and handle failure in the most graceful way you can. This is what almost every app does - consider apps with a save as dialog - they never check the directory is writable, they just attempt the actual write and handle the failure. Mark -- http://mail.python.org/mailman/listinfo/python-list
[issue8170] Wrong Paths for distutils build --plat-name=win-amd64
Mark Hammond skippy.hamm...@gmail.com added the comment: Can't you just install a 64bit Python in a different directory and use that executable to build the 64bit installer? It seems less error prone and should work without manually copying stuff or changing any code. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8170 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8170] Wrong Paths for distutils build --plat-name=win-amd64
Mark Hammond skippy.hamm...@gmail.com added the comment: I don't quite understand how the order will be wrong. Which earlier entry is causing the problem? OTOH though, I also don't quite understand how the build would work at all if a 32bit Python is used to invoke distutils with --plat-name=win-amd64 as the 32bit Python install wont have that PCBuild/AMD64 directory at all - so some more context is needed before I can understand this. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8170 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: asynchronous downloading
On 23/02/2012 5:58 PM, Plumo wrote: I want to download content asynchronously. This would be straightforward to do threaded or across processes, but difficult asynchronously so people seem to rely on external libraries (twisted / gevent / eventlet). Exactly - the fact it's difficult is why those tools compete. (I would use gevent under different circumstances, but currently need to stick to standard libraries.) As above - use threads or processes - they are fine for relatively modest tasks. If your needs go beyond modest, I'd reevaluate your need to stick with just the stdlib - even demanding *sync* http apps often wind up using modules outside the stdlib. Look into virtualenv etc if permission to install packages is the issue. Batteries included free, but turbo-chargers are an extra ;) Mark -- http://mail.python.org/mailman/listinfo/python-list
Re: PythonWin debugger holds onto global logging objects too long
On 7/02/2012 9:48 PM, Jean-Michel Pichavant wrote: Vinay Sajip wrote: On Jan 24, 2:52 pm, Rob Richardson rdrichard...@rad-con.com wrote: I use PythonWin to debug the Python scripts we write. Our scripts often use the log2pyloggingpackage. When running the scripts inside the debugger, we seem to get oneloggingobject for every time we run the script. The result is that after running the script five times, the log file contains five copies of every message. The only way I know to clean this up and get only a single copy of each message is to close PythonWin and restart it. What do I have to do in my scripts to clean up theloggingobjects so that I never get more than one copy of each message in my log files? I don't know what log2py is - Google didn't show up anything that looked relevant. If you're talking about the logging package in the Python standard library, I may be able to help: but a simple script that I ran in PythonWin didn't show any problems, so you'll probably need to post a short script which demonstrates the problem when run in PythonWin. Regards, Vinay Sajip Same here, can't find anything about log2py. Anyway it's possible that your pythonwin does not spawn a clean python interpreter for every run, keeping the same one. That is what everyone's pythonwin does :) It always works in process - not ideal, but also likely to not change. Cheers, Mark So you could possibly keep adding log handlers to your loggers because they may be static objects (like for the standard logging module). One solution would be to empty your logger handler list before adding any. I'm just guessing though, difficult to know without any info on log2py. JM -- http://mail.python.org/mailman/listinfo/python-list
Re: Help with COM_error
Unfortunately this just means that Word threw an error and it's not giving many details about what that might be. Are you sure out_TOC is valid on the other computer? eg, http://stackoverflow.com/questions/3730428/why-cant-i-save-as-an-excel-file-from-my-python-code indicates Office fails in that way when the path isn't valid... Mark On 4/02/2012 12:10 AM, John Lay wrote: I am not a programmer, but this past week I have had a crash course in python scripting am have been rather impressed with myself for having written a fairly complicated script that among many other processes reads a database table via SearchCursor, populates a word template via Bookmarks, then saves the document out as a PDF. The only problem is that it only works on my computer. When I move the script to another computer with the same setup, I continue to receive a Com_error. The script fails at my SaveAs(out_TOC, FileFormat=wdFormatPDF) statement. I have tried both win32com.client and comtypes.client and receive a similar error for both. win32.client: com_error: (-2147352567, 'Exception occurred.', (0, u'Microsoft Word', u'Command failed', u'C:\\Program Files\\Microsoft Office\\Office12\ \1033\\WDMAIN11.CHM', 36966, ), None) comtypes.client: COMError: (-2146824090, None, (u'Command failed', u'Microsoft Word', u'C:\\Program Files\\Microsoft Office\\Office12\\1033\\WDMAIN11.CHM', 36966, None)) It has been suggested that I try python-docx, but I have not been able to get the module to work for me and I have been unable to find any documentation on it. Can anyone help with the com errors? What do they mean? How do I resolve them? Any help would be appreciated. John -- http://mail.python.org/mailman/listinfo/python-list
[issue13892] distutils handling of windows manifest isn't optimal
Mark Hammond skippy.hamm...@gmail.com added the comment: I thought this shouldn't be a problem - that as pythonxx.dll contains a manifest with the references and also contains hoops to ensure its activation context is used when loading dynamic modules, that things should work correctly. The scenario you outline isn't that different to Python being used as a COM server - where a program like cscript.exe, which comes with Windows but I'm pretty sure has no reference to the CRT manifest we care about, loads up a Python COM object, causing Python to be loaded and it to load extension modules - and that works correctly. That said though, I agree it would be nice if the manifest handling was optional, but it isn't immediately clear how that could be done given how distutils is structured. Indeed, there isn't even an obvious way to do it programatically other than by monkey-patching the compiler class. At least if you do take the monkey-patch route, you should find it necessary to only patch one fairly small method in the class. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13892 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7833] bdist_wininst installers fail to load extensions built with Issue4120 patch
Mark Hammond skippy.hamm...@gmail.com added the comment: Actually, I think this is OK - the reference to the x86 is in the tests and those tests don't actually perform a build, just check the manifest is detected and stripped (ie, the test should still work fine on 64bit boxes). Ideally the test could also check a manifest with a 64bit architecture, but I don't think that's really necessary... -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7833 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8418] Crash 0xc0000417 STATUS_INVALID_CRUNTIME_PARAMETER on program exit
Mark Hammond skippy.hamm...@gmail.com added the comment: See also http://bugs.python.org/issue13038 - same exception but in a different content, but the underlying cause may be similar. -- nosy: +mhammond ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8418 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13938] 2to3 fails to convert types.StringTypes appropriately
New submission from Mark Hammond skippy.hamm...@gmail.com: test_types.py converts types.StringTypes to str - but types.StringTypes is a tuple, so expressions like type(x) in type.StringTypes fails after conversion with TypeError: argument of type 'type' is not iterable Attaching a fix and test. Note that the fixer still seems strange after this fix - types.StringType gets converted to bytes but types.StringTypes uses str. This means the expression type.StringType in type.StringTypes evaluates to True in 2.x but False once converted - however, that should probably be tackled in a different bug - the fact the expression now causes a TypeError once converted is more blatantly wrong and the focus of this bug. -- components: 2to3 (2.x to 3.x conversion tool) files: fix_stringtypes_fixer.patch keywords: patch messages: 152592 nosy: mhammond priority: normal severity: normal status: open title: 2to3 fails to convert types.StringTypes appropriately versions: Python 3.2, Python 3.3, Python 3.4 Added file: http://bugs.python.org/file24415/fix_stringtypes_fixer.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13938 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Registry entries set up by the Windows installer
On 2/02/2012 2:09 AM, Paul Moore wrote: I'm trying to get information on what registry entries are set up by the Python Windows installer, and what variations exist. I don't know enough about MSI to easily read the source, so I'm hoping someone who knows can help :-) As far as I can see on my PC, the installer puts entries HKLM\Software\Python\PythonCore\x.y with various bits underneath. I think I've seen indications that sometimes these are in HKCU, presumably for a per user install? If I manually hack around in the registry, and have both HKLM and HKCU, which one will Python use? For setting PYTHONPATH it uses both - HKEY_CURRENT_USER is added before HKEY_LOCAL_MACHINE. I can't recall which one distutils generated (bdist_wininst) installers will use - it may even offer the choice. Furthermore, more of a Windows question than Python, but there's a similar question with regard to the .py and .pyw file associations - they can be in HKLM\Software\Classes or HKCU\Software\Classes. Which takes precedence? No idea I'm afraid, but I'd expect it to use HKCU I assume that the installer writes to HKLM for all users and HKCU for per-user installs. Yep, I think that is correct. Is there anything else I've missed? I'm also not sure which one the pylauncher project will prefer, which may become relevant should that get rolled into Python itself. The reason I ask, is that I'm starting to work with virtualenv, and I want to see what would be involved in (re-)setting the registry entries to match the currently active virtualenv. virtualenvwrapper- powershell seems to only deal with HKCU (which is a big plus on Windows 7, as it avoids endless elevation requests :-)) but that doesn't work completely cleanly with my all-users install. (Note: I'm not entirely sure that changing global settings like this to patch a per-console virtualenv is a good idea, but I'd like to know how hard it is before dismissing it...) Out of interest, what is the reason forcing you to look at that - bdist_wininst installers? FWIW, my encounters with virtualenv haven't forced me to hack the registry - I just install bdist_wininst packages into the parent Python which isn't ideal but works fine for me. This was a year or so ago, so the world might have changed since then. Mark -- http://mail.python.org/mailman/listinfo/python-list
[issue7833] bdist_wininst installers fail to load extensions built with Issue4120 patch
Mark Hammond skippy.hamm...@gmail.com added the comment: ack - that is a really good point. IIRC it can be *. I'll try and look at this over the next day or 2. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7833 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: unittest and threading
Let me have a guess :) On 25/01/2012 7:42 PM, Ross Boylan wrote: On Tue, 2012-01-24 at 13:54 -0800, Ross Boylan wrote: ... The code I want to test uses threads, but that is not entirely internal from the standpoint of the unit test framework. The unit test will be executing in one thread, but some of the assertions may occur in other threads. The question is whether that will work, in particular whether assertion failures will be properly captured and logged by the test framework. I think it will - so long as your test on the main thread hasn't returned yet. Concretely, a test may exercise some code that triggers a callback; the callback might come in a different thread, and the code that is triggered might make various assertions. There are two issues: whether assertions and their failures that happen in other threads will be correctly received by the test framework, and whether the framework is robust against several assertions being raised simultaneously in different threads. The latter seems a bit much to hope for. I suspect both will be fine. I assume that, at a minimum, the my test code will need to use locks or other coordination mechanisms so the test doesn't end before all code under test executes. Yep - that's the only caveat I'd expect . Finally, I'll mention two senses of threads in tests that my question does not concern, although they are also interesting. I am not concerned with testing the performance of my code, in the sense of asserting that an operation must complete before x seconds or after y seconds. Some potential implementations of such tests might use threads even if the code under test was single-threaded. The question also does not concern running lots of unit tests in parallel. nose is still worth having a look at - personally I just use it as a runner and where possible ignore its api... Mark -- http://mail.python.org/mailman/listinfo/python-list
Re: thread example question
On 18/01/2012 4:22 PM, Rodrick Brown wrote:
import _thread as thread
import time
class thread_counter(object):
def __init__(self, thr_cnt, sleep_int):
self.thr_cnt = thr_cnt
self.sleep_int = sleep_int
def counter(myId, count):
for i in range(count):
time.sleep(1)
print('[{}] = {}'.format(myId, i))
def main():
for i in range(5):
thread.start_new_thread(counter, (i, 5))
I think you meant for the following 2 lines to be outside the loop (ie,
to be dedented one level). Once you do that the output is as *I* expect :)
Mark
time.sleep(6)
print('Main thread exiting..')
if __name__ == '__main__':
main()
--
http://mail.python.org/mailman/listinfo/python-list
Re: Losing com pointer
On 7/12/2011 7:22 PM, Matteo Boscolo wrote: Hi all, I need some help to a com problem.. I got this class: class foo(object): def setComObject(comObject): self.comO=comObject #This is a com object from a cad application def showForm(self) # use the self.comO to read some information from the cad application # Show the pyqt form as child of cad application # do somthing with the form # do somthing with the self.comO - Here if pass some time I'm not able to call any method to the com object What are the symptoms of that? ie, what error do you get? I suspect the remote process is going away - it almost certainly has nothing to do with Python itself deciding to make the object go away. Mark a=foo() o=get istance of a cad application via com a.setComObject(o) a.showForm() # here if pass some time I'm not able to call any method to the com object but I I' re call the a.setComObject(o) #Faster and I take less the 30 seconds on the form object it works well It seems a problem of the garbage collector .. but I'm not sure how to debug it .. any help is really appreciated.. it's the last dangerous bug in our application ... Regards, Matteo -- http://mail.python.org/mailman/listinfo/python-list
Re: pythoncom on Windows Server 2008
On 30/11/2011 11:12 AM, Nairn, Bruce wrote: Hi, I’m trying to move some code to a Windows Server 2008 machine. It runs on Windows 7 and XP, but fails on Windows Server 2008. The python installation is seemingly identical (python 2.6.4, 32 bit). The following replicates the problem: import pythoncom IDispatch = pythoncom.CoCreateInstance (‘OPC.Automation’, None, pythoncom.CLSCTX_SERVER, pythoncom.IID_IDispatch) On Windows 7 x64 or Windows XP x32: this returns an PyIDispatch object On Windows Server 2008 x64 this gives: com_error: (-2147221005, ‘Invalid class string’, None, None) Any suggestions would be appreciated! The OPC.Automation object isn't installed on the Server 2008 box. I'm not sure what this object is so can't advise on how to install it. Note also that you will need the same bittedness of the object as Python itself has - ie, assuming a 32bit Python, you need the 32bit implementation of the COM object, or if a 64bit Python, you need the 64bit COM object. Note that both the 32 and 64bit versions of both will work fine on a 64bit version of Windows - you just need to make sure they match. Mark -- http://mail.python.org/mailman/listinfo/python-list
[issue13486] msvc9compiler.py doesn't properly generate manifest files.
Mark Hammond skippy.hamm...@gmail.com added the comment: A manifest seems to be currently created fine - can you provide steps to reproduce the problem you see? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13486 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13320] _remove_visual_c_ref in distutils.msvc9compiler causes DLL load fail with embedded Python and multiple CRT versions
Mark Hammond skippy.hamm...@gmail.com added the comment: I can't explain why this might be happening given the Python dll is still build against vc9 - I'm guessing this can't be reproduced without vs10 in the mix? Re making the feature optional - distutils doesn't really lend itself to customizing the compiler best I can tell - the only answer I know of here is to provide your own compiler sub-class and override manifest_get_embed_info to return the manifest filename. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13320 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Need Windows user / developer to help with Pynguin
On 30/10/2011 1:43 AM, Lee Harr wrote: For Windows users who want to just run Pyguin (not modify or tinker with the source code), it would be best to bundle Pynguin up with Py2exe I considered that, but I agree that licensing issues would make it problematic. What licensing issues concern you? The py2exe license shouldn't be a problem and py2exe or something like it is good advice. Mark -- http://mail.python.org/mailman/listinfo/python-list
Re: logging: warn() methods and function to be deprecated.
On 22/10/2011 11:09 PM, Vinay Sajip wrote: In response to an issue (#13235) raised on the Python bug tracker, I'm going to deprecate the warn() methods in the Logger and LoggerAdapter classes in the stdlib logging package, as well the module-level warn() function. The warn() variants were synonyms for the warning() methods and function, and a holdover from before the time that logging was added to Python.They were not documented; it's probably time to retire them, so I've added a DeprecationWarning to appear in 3.3, and they'll be completely removed in 3.4 (along with the WARN synonym for WARNING). With this change, all the logging levels are adjectives which apply to the logged message: DEBUG, INFO, WARNING, ERROR and CRITICAL. I don't believe the WARN/warn variants were used much, if at all - but this is just a heads up for anyone who might have used them. I think that is a real shame - it seems to be gratuitous breakage for almost zero benefit. That issue shows that Trac makes heavy use of .warn, I've use .warn almost exclusively for many years, and code.google.com shows it is used extensively in the wild. Is there still a chance to reconsider? Mark -- http://mail.python.org/mailman/listinfo/python-list
Re: need python+windows edit control help
On 22/10/2011 10:30 AM, Eric S. Johansson wrote: I'm back with yet another attempt at adding accessibility features using Python and NaturallySpeaking. I've simplified the concepts again and I really need some help from someone who knows Microsoft Windows and Python. My goal is developing a template for what I'm trying to do, then I can take over and generate some useful accessibility tools. The python-wi...@python.org mailing list might be the best place to look for help - although you will probably need to provide much more information before anyone can help. MSDN documents most of what you can do with edit control (look for windows messages starting with EM_), but without checking, I expect you will find programs like Skype don't use a Windows edit control at all. Mark -- http://mail.python.org/mailman/listinfo/python-list
[issue12989] Consistently handle path separator in Py_GetPath on Windows
Mark Hammond skippy.hamm...@gmail.com added the comment:
The first chunk of that patch is for when pythonhome==NULL. There is also a
similar block just under it when MS_WINDOWS is not defined. While I don't know
in which cases this will be built without that define, it looks as though the
*buf++ = DELIM; should also be added to that block?
Also, there is an existing conditional:
if (argv0_path) {
which can never be false (as argv0_path is a char array). It could be changed
to if (argv0_path[0]) but ISTM that it could also be removed completely - ie,
the 2 lines left in that block should have no effect in the case where the
buffer is empty.
I haven't actually tested it though, but apart from the first comment above, it
*looks* like it does the right thing :)
--
nosy: +mhammond
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12989
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4431] Distutils MSVC doesn't create manifest file
Mark Hammond skippy.hamm...@gmail.com added the comment: I don't think a buildbot will be necessary - like the earlier compilers, they may have basic support but they don't all get buildbot support. The problem isn't the lack of ability/will to get things working with VS2010 - it is more the lack of incentive to add another compiler to the mix. OTOH, seeing it is nearly 2012, a case could certainly be made to move 3.3 to that compiler :) I'm interested to see the patch required to get it working - almost every other upgrade has been almost handled completely by the VS upgrade process so it would be good to see how different this one is - so please CC me on any new issue you create. I'm also interested to know how mixing the CRTs is causing problems - are you using the very few Python APIs impacted by such mixing, or is the issue more about needing to redistribute both, or something else entirely? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4431 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7833] bdist_wininst installers fail to load extensions built with Issue4120 patch
Mark Hammond skippy.hamm...@gmail.com added the comment: I pushed the changes to 2.7, 3.2 and 3.3. I'm happy to help with distutils2/packaging but I'll need to do that later once I work out where to start :) Therefore I'm not yet closing this issue. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7833 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4431] Distutils MSVC doesn't create manifest file
Mark Hammond skippy.hamm...@gmail.com added the comment: My experience is that for VS2008 at least, the /MANIFESTFILE: option seems to be ignored if there is nothing to put in the manifest, and this tends to be true if you use a static CRT instead of the DLL based one (ie, if you use /MT) Issue 7833 has a patch designed to both (a) remove the manifest entirely if the only assembly reference is to the CRT and (b) give the setup.py author finer control over this behaviour. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4431 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7833] bdist_wininst installers fail to load extensions built with Issue4120 patch
Mark Hammond skippy.hamm...@gmail.com added the comment: New version of the patch with the small tweaks requested plus a NEWS entry. -- Added file: http://bugs.python.org/file23400/bug-7833-tweaks-plus-news.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7833 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Implementing Python-OAuth2
On 11/10/2011 7:16 PM, Kayode Odeyemi wrote: On Thu, Oct 6, 2011 at 5:15 PM, Jeff Gaynor jgay...@ncsa.illinois.edu mailto:jgay...@ncsa.illinois.edu wrote: On 10/06/2011 08:34 AM, Kayode Odeyemi wrote: Hello friends, I'm working on a pretty large application that I will like to use oauth2 on as an authentication and authorization mechanism. I understand fairly the technology and I have written my own implementation before I stumbled on python-oauth2. I need advise on leveraging python-oauth2 api for creating consumer key, creating consumer secret, access token and token secret. This works well, but be advised that the original python oauth library had some serious issues, so was redone as python-oauth2. What is confusing is that it refers to OAuth version 1.0a, not the upcoming OAuth version 2.0, so make sure you read the right spec before using it, since they are very different indeed. There are *no* usable OAuth version 2..0 implementation in any language (usually Java comes first) that I know of, so you will get to role your own, which is hard. There are a few beta-level versions E.g. Twitter) but these are special cased to the author's needs. The spec itself is not quite ready either and since it has changed quite substantially in the last year, I suspect that everyone is waiting to see it settle to a steady state. Jeff, I'm in the middle of a big confusion here and will need your help. I will like to know, can the request be signed just once and for all subsequent request made, I can use the stored nonce, signature method and token? My kind of setup is such that, I want the client app to be registered once, such that for every request to a resource, as long as the required parameters are available in the header (which would have been gotten at the initial request), access is granted. Is this a correct interpretation of Oauth? I believe every request must be resigned with a new nonce and new timestamp using the tokens it initially fetched during the auth step so replay attacks can be prevented. It might be true that some server implementations don't check the timestamp or nonce, so it *might* work for some servers if the exact same request parameters are used, but such servers are simply insecure and broken. Mark -- http://mail.python.org/mailman/listinfo/python-list
[issue7833] bdist_wininst installers fail to load extensions built with Issue4120 patch
Mark Hammond skippy.hamm...@gmail.com added the comment: Thanks for the review. One note: | +def manifest_setup_ldargs | I’d make all new methods private ones (i.e. leading underscore). They aren't strictly private and are designed to be overridden by subclasses (although in practice, subclassing the compiler is much harder than it should be, so pywin32 monkey-patches the instance.) This is actually the entire point of my updated patch - to give setup.py authors some level of control over the manifest behaviour. I do intend forward-porting to 3.3 and also to check it is is too late for 3.2 (a quick check before implied it might be OK, but I'm not sure) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7833 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7833] bdist_wininst installers fail to load extensions built with Issue4120 patch
Mark Hammond skippy.hamm...@gmail.com added the comment: My apologies Eric - I had completely overlooked those tests. Attaching a new patch with a test. Note the existing test doesn't actually perform a build so the new test also doesn't, but it does check the core logic (ie, that a manifest with only the msvcrt reference gets it scrubbed). -- Added file: http://bugs.python.org/file23341/bug-7833-overridable-manifest-settings-with-test.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7833 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7833] bdist_wininst installers fail to load extensions built with Issue4120 patch
Mark Hammond skippy.hamm...@gmail.com added the comment: I'm reluctant to commit to adding test infrastructure for the distutils build commands - if I've missed existing infrastructure and adding such tests would actually be relatively simple, please educate me! Or if someone else would like to help with the infrastructure so I can test just this patch, that would be awesome. But I don't think this fix should block on tests given it can easily be tested and verified manually. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7833 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13101] Module Doc viewer closes when browser window closes on Windows 8
Mark Hammond skippy.hamm...@gmail.com added the comment: For some reason, IE is struggling to even display the page - it just seems to sit there loading the page without displaying anything, but hitting stop then refresh usually brings it up. But if you kill IE (which best I can tell can only be done via the task manager - it has no other Windows controls) the doc server process does also terminate. If you run the doc server using python.exe, you will notice tracebacks in the console due to the socket connection being reset (which is probably related to the above problems - the socket should have been fully read by the time you manage to kill IE) - but using python.exe the process stays alive serving requests. I *guess* that the problem is pythonw.exe is hitting an error when it attempts to print to the invalid stderr handle. It might be possible that somehow under Windows 8, stderr isn't buffered (or has as large of a buffer) as other Windows versions, so dies when a small amount of data is written to stderr - but I suspect the same problem could be provoked on other Windows versions by arranging for 8k of connection reset by peer tracebacks to be written, at which point the buffer is attempted to be flushed and fails. Here endeth my speculation for the day ;) -- nosy: +mhammond ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13101 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7833] Bdist_wininst installers fail to load extensions built with Issue4120 patch
Mark Hammond skippy.hamm...@gmail.com added the comment: This is biting people (including me :) so I'm going to try hard to get this fixed. One user on the python-win32 mailing list resorts to rebuilding every 3rd party module he uses with this patch to get things working again (although apps which use only builtin modules or pywin32 modules - which already hacks this basic functionality in - don't see the problem.) I'm attaching a different patch that should have the same default effect as Christoph's, but also allows the behaviour to be overridden. Actually overriding it is quite difficult as distutils isn't setup to easily allow such compiler customizations - but at least it *is* possible. To test this out I hacked both the pywin32 and py2erxe build processes to use those customizations and it works fine and allows them both to customize the behaviour to meet various modules' requirements. Finally, this whole thing is still fundamentally broken for extensions which need a manifest (eg, to reference the common controls or the requestedExecutionLevel cruft). These extension will still need to include the CRT reference in their manifest and thus will need a copy of the CRT next to each of them. I *think* this also means they basically get a private copy of the CRT - they are not sharing the CRT with Python, which means they are at risk of hitting problems such as trying to share FILE * objects. In practice, this means such modules are probably better of just embedding the CRT statically. This is the route I've taken for one pywin32 module so the module can have a manifest and still work without a complete, private copy of the CRT needing to live next to it. But even with that problem I think this patch should land. It would be great if someone can review and test this version of the patch and I'll check it in. -- versions: +Python 3.3, Python 3.4 -Python 2.6 Added file: http://bugs.python.org/file23305/bug-7833-overridable-manifest-settings.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7833 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: pyWin build 216
On 24/09/2011 12:25 AM, python wrote: I have used pyWin for several years now with out issue. I recently installed build 216 for python 2.7 on windows XP pro. The program crashes every time I exit a wxPython program and has crashed a few other times. There are a number of issues using Pythonwin to run a program which uses a different UI toolkit (eg, wx, Tkinter) and while these have been around for many years I don't plan on trying to fix it. IOW, don't do that :) I does not seem that pyWin has been updated since February of this year. Is there a direction change for the windows extensions? Is it time I make the move to 3.x? Mark Hammond has given much to the Python community and I do not intend for this post to be negative in any way. No problem. There have been no updates as there is very little to update (ie, the code hasn't change a huge amount in hg since then). There will probably be a new version in the next month or so, but that is quite orthogonal to whether you should move to 3.x - the 3.x version of Pythonwin hasn't been updated in the same period and is built from the same source tree, so is likely to have exactly the same problems (infact is likely to have a few more - there are probably a few 3.x specific issues still hiding away). Mark -- http://mail.python.org/mailman/listinfo/python-list
Re: PyEval_EvalCodeEx return value
On 20/09/2011 8:34 PM, Mateusz Loskot wrote: Hi, I'm trying to dig out details about what exactly is the return value the of PyEval_EvalCodeEx function in Python 3.x The documentation is sparse, unfortunately. Perhaps I'm looking at wrong function. My aim is simple, I need to execute Python code using Python interpreter embedded in my C++ application. The Python code is a simple script that always returns single value. For example: #! /usr/bin/env python def foo(a, b): return a + b f = foo(2, 3) But, f can be of different type for different script: one returns numeric value, another returns a sequence, so the type is not possible to be determined in advance. I know how to capture Python stdout/stderr. I also know how to access the f attribute using PyObject_GetAttrString and then I can convert f value to C++ type depending on PyObject type. However, I guess there shall be a way to access f value directly from PyEval_EvalCode return object: PyObject* evalRet = ::PyEval_EvalCode(...); But, I can't find any details what the evalRet actually is. Eval is to eval an expression. If you simply eval the expression f in the context of the module you should get the result returned. Obviously though it is designed to eval more complex expressions and in your specific example, doing the getattr thing will also work fine. Mark -- http://mail.python.org/mailman/listinfo/python-list
Re: import os or import os.path
On 7/09/2011 7:47 AM, Ian Kelly wrote:
On Tue, Sep 6, 2011 at 3:25 PM, Jabba Lacijabba.l...@gmail.com wrote:
Hi,
If I want to use the 'os.path' module, it's enought to import 'os':
import os
if os.path.isfile('/usr/bin/bash'):
print 'got it'
In other source codes I noticed that people write 'import os.path' in
this case. Which is better practice?
import os.path is better practice. There is no guarantee in general
that the os module will automatically import os.path, and in future
versions or different implementations it might not.
That's probably a matter of opinion - eg,
http://docs.python.org/tutorial/interpreter.html has an example of
importing the os module then accessing os.path.
Personally I think directly importing os.path is a waste of precious
keystrokes ;)
Cheers,
Mark.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Dynamically linking python into my vc project - help required
On 3/08/2011 6:58 PM, mrinal...@edss.co.in wrote: Hi, I am trying to embed python into my MFC application. I have done this before by statically linking to the python lib. But I want to change this now. The idea is to take the information from the registry for the installed version of python on the target machine. Then load python using loadlibrary call and use the functions from python using pointers to functions returned by GetProcAddress . ... PyObject* pObject = pFPyEval_EvalCode((PyCodeObject*)pCodeObject, m_Dictionary, m_Dictionary); } I am facing two problems here , though I want to link to python dynamically I am required to include python.h for my code to compile the following declaration. PyObject* pCodeObject You can probably just define pFPyEval_EvalCode as taking a PyObject * (but I'm not sure where you are getting a declaration of PyObject * from) I tried copying some of the python definitions including PyObject into a header in my mfc app. Then it complies fine. but Py_CompileString call fails. so finally I am unable to run script from my MFC application by linking to python dynamically. Are you sure you have the calling convention correct on those function pointer decls? How can this be done ? Please help. Is there a different approach to linking to python dynamically. Please could you write to me ? py2exe takes the same basic approach as you and might be worth copying its declarations for the function pointers? Mark -- http://mail.python.org/mailman/listinfo/python-list
[issue11629] Reference implementation for PEP 397
Mark Hammond skippy.hamm...@gmail.com added the comment: The most recent version of PEP397 has removed all mentioned of this reference implementation - the C implementation at https://bitbucket.org/vinay.sajip/pylauncher/ is now the reference. -- resolution: - out of date status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11629 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Python 2.7.2 for Windows reports version as 2.7.0?
On 18/06/2011 1:36 PM, pyt...@bdurham.com wrote: Hi Benjamin, The file info is seems correct but I just checked the MSI and it's reporting that it's 2.7.2. How exactly are you running python.exe and IDLE- are you calling the full path, just calling python and using whichever python version is first on your path, or are you using an entry in the start menu? The only thing I can think of is that your 2.7.0 install is in a different location than your 2.7.2 install. So 2.7.2 installed correctly but you're still running the old one. Within the folder where the python.exe exists, I have tried the following, all of which report Python 2.7.0 vs. 2.7.2 python python.exe c:\python27 Confirming I'm running what I think I'm running: import sys sys.hexversion 34013424 sys.executable 'C:\\Python27\\python.exe' And confirming the exe files in my Python27 folder: Directory of C:\Python27 06/12/2011 03:09 PM26,624 python.exe 06/12/2011 03:06 PM27,136 pythonw.exe Anyone else having the same experience? Malcolm The version info comes from the DLL - I wonder if the DLL being found is somehow old? Make sure: import sys win32api.GetModuleFileName(sys.dllhandle) Is the DLL you expect. Mark -- http://mail.python.org/mailman/listinfo/python-list
Re: Multiple windows services on the same machine
On 6/06/2011 2:54 AM, Massi wrote: Hi everyone, I'm writing a script which implement a windows service with the win32serviceutil module. The service works perfectly, but now I would need to install several instances of the same service on my machine for testing purpose. This is hard since the service name is hard-coded in the service class definition: class MyService(win32serviceutil.ServiceFramework) : _svc_name_ = 'MyService' _svc_display_name_ = 'Instance ofMyService' It is only hard-coded in the HandleCommandLine function - you probably just want your own argv parsing and call InstallService directly. HTH, Mark -- http://mail.python.org/mailman/listinfo/python-list
Re: Distutils beginner question - windows
On 3/06/2011 6:57 PM, Seb S wrote: Hi all, Just a quick question , I have a simple script I want to convert into a windows installer and give to some friends. I had a look at http://docs.python.org/distutils/introduction.html and wrote this setup script: #!/usr/bin/env python from distutils.core import setup setup(name=C:\data\Sendmailmsg.py, version='1.0', description='Python Distribution Utilities', author='Sebas929', author_email=' ', url=' ', py_modules=['urllib','smtplib'], ) I tried to run this - C:\Data\Setup.py bdist_wininst - in a cmd prompt. C:\Data\ contains my script Sendmailmsg.py and Setup.py I am getting the error : I think you misunderstand what bdist_wininst is for and probably want py2exe (where you just tell it you want to package Sendmailmsg.py and it finds all other dependent modules like smtplib etc, bundles them up with a full python runtime and rolls it into a nice executable) HTH, Mark -- http://mail.python.org/mailman/listinfo/python-list
[issue12200] bdist_wininst install_script not run on uninstall
Mark Hammond skippy.hamm...@gmail.com added the comment: Adding tests would be fairly painful - there is no test infrastructure in place for generating and running installers at all, and worse, the changes are likely to not work correctly when run from a Python build tree when the built DLL is not installed into System32 (the patch basically assumes an installed dir structure rather than a built one.) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12200 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12200] bdist_wininst install_script not run on uninstall
Mark Hammond skippy.hamm...@gmail.com added the comment: (OTOH though, I could tweak the patch to work in a built tree - it would mean appending PCBuild to the dir and retrying the DLL load if the other options fail...) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12200 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12200] bdist_wininst install_script not run on uninstall
Changes by Mark Hammond skippy.hamm...@gmail.com: -- assignee: tarek - mhammond keywords: +patch stage: - patch review versions: +Python 2.7, Python 3.2, Python 3.3, Python 3.4 Added file: http://bugs.python.org/file22205/issue12200.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12200 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: bdist_wininst: install_script not run on uninstall
On 26/05/2011 6:00 PM, Wilbert Berendsen wrote: Op donderdag 26 mei 2011 schreef Mark: Wilbert wrote: can anybody find out why the install script is not run? Works for me in the pywin32 install script - maybe you should make the smallest possible example that doesn't work and post the entire thing here? Sorry, I was wrong. It apparently does *not* work for me either :( This is a bug in distutils/bdist_wininst - I just created http://bugs.python.org/issue12200 with the details and your samples, and sadly I can't think of a work around you can use until this is fixed (which I might get to soon, but not this weekend...) Cheers, Mark -- http://mail.python.org/mailman/listinfo/python-list
[issue12200] bdist_wininst install_script not run on uninstall
New submission from Mark Hammond skippy.hamm...@gmail.com: Probably in all versions, but certainly in 2.7. If you create an installer with bdist_wininst and specify an install_script, that script is not run on uninstallation. See attached test case: setup.py specifies an install_script which just appends argv to %TEMP%/uninstall-test.txt. * Create the installer with python setup.py bdist_wininst * Execute the installer (ie, dist\hello-0.1.win32.exe) * Check %TEMP%/uninstall-test.txt - it should have 1 line: ['o:\\src\\python-2.6\\Scripts\\hello-install.py', '-install'] * Uninstall the package. * Check %TEMP%/uninstall-test.txt - it *should* have a new line reflecting the uninstall. Instead it is unchanged. To get more info: * Reinstall the package. * Manually uninstall using the cmdline (with adjusted paths) C:\ c:\python26\Removehello.exe -u c:\python26\hello-wininst.log %TEMP%\delme.out 21 Check the contents of %TEMP%\delme.out - you will see: *** Could not load Python ** Could not run installation script *** Digging into the source code of install.c - the problem is that although the Python DLL name is parsed from the log file, this isn't reflected in the global variables python_dir or pythondll - so they remain empty strings and attempting to load the empty string as Python causes the error messages. -- assignee: tarek components: Distutils files: setup.py messages: 137105 nosy: eric.araujo, mhammond, tarek priority: normal severity: normal status: open title: bdist_wininst install_script not run on uninstall type: behavior Added file: http://bugs.python.org/file22160/setup.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12200 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12200] bdist_wininst install_script not run on uninstall
Changes by Mark Hammond skippy.hamm...@gmail.com: Added file: http://bugs.python.org/file22161/hello.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12200 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12200] bdist_wininst install_script not run on uninstall
Changes by Mark Hammond skippy.hamm...@gmail.com: Added file: http://bugs.python.org/file22162/hello-install.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12200 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: bdist_wininst: install_script not run on uninstall
On 26/05/2011 5:28 AM, Wilbert Berendsen wrote: Hi, according to the docs the installer bdist_wininst creates will run the install-script on install with -install (which works perfectly) and on uninstall with the -remove argument (which seemingly never happens). However I want to cleanup some registry stuff on uninstall so I want the uninstall script to work. Studying the source code of the installer[1] in the Run_RemoveScript function... [1] http://svn.python.org/view/python/trunk/PC/bdist_wininst/install.c ... it checks for the line '%d Run Script: %s' in the log, which is there. But can anybody find out why the install script is not run? Works for me in the pywin32 install script - maybe you should make the smallest possible example that doesn't work and post the entire thing here? Mark -- http://mail.python.org/mailman/listinfo/python-list
