Just a question. What is the reason the win32 extensions are shipped separately? Is it a licensing issue or is there another reason? Massimo
Massimo Di Pierro <massimo.dipierro@gmail.com> writes:
Just a question. What is the reason the win32 extensions are shipped separately?
This might better be asked on the developers's forum; this forum is for discussing changes to Python.
Is it a licensing issue or is there another reason?
Here is a message to consider for information about this issue <URL:http://bugs.python.org/issue4954#msg85994>. -- \ “I think Western civilization is more enlightened precisely | `\ because we have learned how to ignore our religious leaders.” | _o__) —Bill Maher, 2003 | Ben Finney
On Tue, Sep 13, 2011 at 1:22 PM, Ben Finney <ben+python@benfinney.id.au> wrote:
'Why is it so?' questions are perfectly reasonable fodder for python-ideas (since they're usually a precursor to "let's do it differently"). Part of the reason this list exists is so misunderstandings of why Python is the way it is can be clarified here without generating traffic on the main development list.
I'm not sure why you linked that - it's about the need to use Visual Studio to safely build C extensions on Windows, not about why the CPython Windows installer doesn't bundle pywin32 the way ActiveState (and, IIRC, Enthought) do. The Python 3 series defines a stable ABI (PEP 384) that eliminates that restriction. As far as the original question goes, Mark Hammond would be the person in the best position to answer that. I don't know much about how pywin32 development works, and I'm not sure any of the other core devs do, either. The 'pywin32' web presence is fragmented enough that it isn't easy to find out more. (The SF project pages are at http://sourceforge.net/projects/pywin32/ and there seems to be some discussion at http://mail.python.org/mailman/listinfo/python-win32, but there's all sorts of stale information floating around which means that Google doesn't help much, either) Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Mon, Sep 12, 2011 at 9:26 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:
(Of course, for some folks python-ideas is the only list they read. :-) Regarding the original question, it's definitely not a licensing issue. Mark originally intended for pywin32 to be merged back into core Python, and I recall looking at this option seriously. I believe it was not a single issue that held it back, but a combination of factors: sheer size, coding style, robustness of the code (you can definitely cause crashes by passing bad arguments to pywin32 code), the dependency on a specific platform and compiler, the fact that no other core developer knew the codebase, and the different development speeds of core Python and pywin32. There may also have been some qualms about who was to build the installer. In the end we compromised: the core Python distro does not include pywin32all, but the download instructions contain a recommendation. For example, the Python 2.2 download page (http://www.python.org/download/releases/2.2/) says: "Windows users may also be interested in Mark Hammond's _win32all_, a collection of Windows-specific extensions including COM support and Pythonwin, an IDE built using Windows components." I don't know why that was dropped from the main release page for 2.3 and later; the same recommendation is still found on http://www.python.org/download/windows/ which is linked from a tab labeled "Windows" on all release pages. I assume that the development speed on pywin32 has slowed down to the point where we could consider including it in the core Windows installer. But I'm not sure if the logistics of building and testing the installer easily support this. There's also the impression (possibly wrong) that pywin32/win32all is somewhat dated, and hasn't changed much since the glory days of Windows 98. But actual developers using Python on Windows should be the judge of that. -- --Guido van Rossum (python.org/~guido)
Guido van Rossum wrote:
I think that's mainly because the thing it's wrapping -- the win32 api -- is somewhat dated, and hasn't changed much since the glory days of Windows 98. :-) By today's standards, the traditional win32 gui api is hopelessly cruddy. Unfortunately, the only efforts on Microsoft's part to replace it with something better seem to be taking place in the .NET world. As things stand, this places them out of the easy reach of Python. Adding something to the stdlib enabling Python to call .NET libraries would open up considerable new opportunities. Maybe it could be based on this: http://pythonnet.sourceforge.net/ -- Greg
On Tue, Sep 13, 2011 at 20:08, Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
Could we skip inclusion the win32gui stuff? We'd be including something which has been surpassed by WinForms, which itself has (mostly?) been surpassed by WPF, and soon enough we'll have Metro...on top of the fact that we'd be introducing a second way to do GUI work alongside Tkinter.
Do we really need to be encouraging use of Windows APIs in Python? Given the greater user base of Windows, is there a danger this could encourage the littering of Windows-only "workarounds" in many projects? "Well Python doesn't ship with a usable GUI toolkit (hi tk), but it does ship with Win32"->"Everyone uses Windows anyway, lets make a Win32 interface". Just a thought. On Wed, Sep 14, 2011 at 11:22 AM, Brian Curtin <brian.curtin@gmail.com> wrote:
On Tue, Sep 13, 2011 at 21:28, Matt Joiner <anacrolix@gmail.com> wrote:
Do we really need to be encouraging use of Windows APIs in Python?
I don't think we're encouraging anything, nor do I think we need to. People have already been doing so for quite some time - it's a fact of life. If I want to write a tool which uses Windows' ReadDirectoryChangesW API, how do I do that today? I either write a C extension (which I've done), or I use pywin32. I must be missing something, because your question comes off as saying "don't solve that problem".
I don't think the inclusion of this package is going to enlighten people on the ability to make platform specific workarounds in their code. They've already been doing this with pywin32 or extension modules where necessary, and I don't think that's a such bad thing. Obviously it's great when Python provides a way to solve a cross-platform problem with one solution, e.g., listing directory contents, but it's not all sunshine and rainbows. Sometimes working with those contents requires a platform specific operation.
On Wed, Sep 14, 2011 at 1:19 PM, Massimo Di Pierro <massimo.dipierro@gmail.com> wrote:
For me the only reason win32 is important is to implement a cross-platform file locking. I did not mean to propose web32 should be included but a portable file locking api would be useful.
If Windows developers wanted to work with Mark Hammond to figure out and systematically extract a core subset of stable pywin32 functionality potentially suitable for inclusion in the standard library, that may not be a bad thing (there's currently already duplication between the two, since the stdlib needs aspects of the win32 API to implement modules like subprocess and multiprocessing, but in those cases the pywin32 version is almost always more feature complete). The stdlib version could evolve as the standard library does, while pywin32 could move a bit quicker in responding to releases of new versions of Windows. However, CPython+pywin32 suffers from the curse of being a "good enough" solution most of the time (especially if you start with a bundled installer that takes care of finding a suitable version of pywin32 for the version of CPython being installed). Personally, I do think this idea has potential to be a valuable project, but I also think the same could be said just for helping pywin32 consolidate its web presence and promote itself more clearly. Currently, a Google search for pywin32 gives you: ~4 hits on the SourceForge project. This is *correct*, but SF in general (and currently pywin32 in particular) is organised for existing developers, not for users or potential new developers (finding the latest release and being sure it *is* the latest release is not trivial - more on this below). The next hit is on Mark's old starship page - that's ancient and hasn't been used for pywin32 downloads in years Next we have the PyPI page, which appears to be a couple of releases out of date (SF has 216, PyPI has 214) Then we have two copies of the PyPI documentation, one hosted by ActiveState (as part of the ActivePython 2.7 docs), the other by Tim Golden. Assuming Mark was happy to go along with the idea, it would be great to see some real content at http://pywin32.sourceforge.net/ instead of the current placeholder page. For example: - quick description of the project and how it can really help with Windows-specific development (and general Windows compatibility) - link directly to latest download file on Sourceforge - link to PyPI entry - link to the user mailing list (python-win32@python.org, I believe) - basic instructions on how to get involved as a developer As an even larger task, it would be great to see some Sphinx docs for Pywin32 that provided an overview of the various modules included in the package, and references out to the relevant MS documentation (as well as to the automatically generated documentation for pywin32 itself). Regards, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
I would help but I do not feel competent as I am not a windows user. For portability reasons I have had a need for: win32con.LOCKFILE_EXCLUSIVE_LOCK win32con.LOCKFILE_FAIL_IMMEDIATELY win32file._get_osfhandle win32file.LockFileEx pywintypes.OVERLAPPED() Although I have not used this much, the ability to talk to windows app is also useful: import win32com.client xl = win32com.client.Dispatch("Excel.Application") Massimo On Sep 13, 2011, at 11:12 PM, Nick Coghlan wrote:
Well... ReadDirectoryChangesW is present in pyfilesystem, that Nick mentioned in another thread. In fairness you shouldn't expose this without exposing inotify for Linux, and whatever nasty equivalents are available on other systems. pywin32 gives you full access to the Windows kernel interface. The same functionality is not bundled in the standard library for Linux. To use Massimo's example regarding file locking, just this morning I had to write a ctypes wrapper around struct flock for this purpose because the fcntl module is only a partial implementation. If the full Windows API is made available, you might as well complete some of those half-done modules now that the single biggest sore thumb (Windows) for OS interfaces will be laid bare. Python is well respected for its cross platform support. Making bindings available in both cross platform and native forms will greatly improve uptake of Python. My thoughts are that more effort should be made to completely expose Unix/Linux/Mac interfaces before (or simultaneously) with making the entire Windows API available. On Wed, Sep 14, 2011 at 1:00 PM, Brian Curtin <brian.curtin@gmail.com> wrote:
On Tue, Sep 13, 2011 at 23:13, Matt Joiner <anacrolix@gmail.com> wrote:
pywin32 gives you full access to the Windows kernel interface. The same functionality is not bundled in the standard library for Linux.
Correct me if I'm wrong, but it doesn't exist.
Mark or someone could probably answer this question in a second, but I've tried to find a date for when pywin32 was first released, which is kind of tough. win32all build 135 added Python 2.0 support, which was released in October 2000, so I suspect that build occurred close to that time. There are 29 releases listed before that one on http://python.net/crew/mhammond/win32/RecentChangeHistory.html (and potentially more elsewhere, as the list only goes to 106), all going back to the Python 1.x times. Do we really need to hold back a 10+ year old project because no one thought to do the same thing for other platforms? I don't disagree that having bindings for all popular platforms is a good thing, but we'll be on Python 5 by the time we can wrangle up people to write all of that code, maintain it, and watch it mature while helping it find wide reaching adoption. Mark released the book "Python Programming on Win32" in January 2000, which I still have on my desk despite it barely surviving a flooded basement, and it's almost all based on this package. It was mature enough even then to write most of a 600+ page book with, which puts it in a very small camp of projects.
2011/9/14 Matt Joiner <anacrolix@gmail.com>
We already have platform-specific modules on stdlib. ;) Have you written any interactive command-line interpreter in Python? It's great if you are using an Unix-like o.s., since the readline module can be used, but Windows programmers can't do the same. -_- As a programmer, I use Python to help on solving my problems, whatever the platform I was using to develop for. If I need to make a Windows-only project, there's nothing that Python can do to stop me. But I'll definitely appreciate it, if it can make my life easier on doing this. Regards, Cesare
Cesare Di Mauro wrote:
I agree, and it'll be interesting to know if encouraging the use of Linux or OS X APIs raises such "questions" as well...
We already have reasonably good third-party wrappers for GUI facilities on the other platforms -- PyObjC on MacOSX, and pygtk on Linux. We don't have anything equivalent for recent Windows technologies, though. -- Greg
Georg Brandl wrote:
Gtk isn't any more a platform facility than Qt is.
It's the closest thing we have to a platform-native GUI facility in the Linux world, though. It's not the *only* one -- there are others, such as KDE. But if you work in a Gnome environment, all the system stuff is built on it, and it defines the look and feel that you expect apps to have. So it occupies much the same place that Cocoa does on MacOSX. -- Greg
Well technically not. KDE mostly supplements Qt, A few objects here and there make use of some Qt features. The gobject, glib combination are bound up in numerous low level system services and supplementary libraries that have nothing to do do with GUIs, even I think on a KDE system. That said, if system GUI capable APIs are to be exposed on the standard library, those should be Win32, Cocoa, and GTK+. On Sep 16, 2011 2:11 PM, "Georg Brandl" <g.brandl@gmx.net> wrote:
On Fri, Sep 16, 2011 at 6:25 PM, Matt Joiner <anacrolix@gmail.com> wrote:
The freedesktop.org standard APIs are a mix of services that originated in various parts of the Linux software stack. Some originate from x.org, some from Gnome/Gtk, some from KDE/Qt. I've yet to see a Gtk based app that feels native on KDE, mainly because the Gtk file dialogs are so atrocious and fd.org has yet to standardise things to the point where the apps designed for each environment can invoke each other's system dialogs. Regardless, there are going to be limits to what the standard library can realistically keep up to date with when it comes to platform-specific support. The cutting edge for the various platforms is always going to require third party libraries. It may be that there are stable subsets of functionality that *could* be included in the standard library (there are certainly plenty of *nix specific wrappers for system APIs), but the existence of those are predicated on interested parties stepping up to maintain them in accordance with python-dev policies. And really, it doesn't gain all that much - if you're targeting a specific platform, you're probably going to want the up-to-date platform specific libraries *anyway*. If you don't, then the cross-platform stuff in the core will likely suffice. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
Am 16.09.2011 10:25, schrieb Matt Joiner:
Well technically not. KDE mostly supplements Qt, A few objects here and there make use of some Qt features.
This is not quite true: just grep for "Q" through the KDE headers. Most objects there are QObjects, and the basic signal-slot mechanism comes from Qt, as well. But I will stop here, since it's not the point of the discussion. It's just not true that Gtk is "the" blessed toolkit for X11. (Just like Vim is not the one true editor :) Georg
2011/9/16 Matt Joiner <anacrolix@gmail.com>
And .NET too, since it's a Windows technology which you'll find on any Windows >= Vista (but also installable on XP). It doesn't mean that we necessarily need to wrap every single win32 and/or .NET API into a Python package on the stdlib. ctypes is useful to access whatever you want (win32 and any DLL, OS X dynamic libraries, Linux .so). Python for .NET can do the same for .NET, and is small enough to be made available on the stdlib. I think that something similar can be provided for OS X and Linux through Mono. Regards, Cesare
On 17 September 2011 07:30, Cesare Di Mauro <cesare.di.mauro@gmail.com>wrote:
Python.NET is basically unmaintained, and requires very specialised knowledge to develop. I don't think it's in a position to move it into the standard library. For accessing .NET from Python IronPython is a much better alternative (with caveats about the use of C extensions that apply to any of the alternative implementations). All the best, Michael
-- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html
On 22 September 2011 01:12, Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
That in itself doesn't make adding Python.NET to the standard library feasible... Michael
-- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html
Georg Brandl wrote:
And if you work in a KDE environment, all its stuff is built on Qt. I really don't see how the two are on different levels.
I'm not necessarily saying that they are, only that gtk as it exists on Linux is at no *higher* a level than Cocoa or the win32 api are on their respective platforms, and that there is nothing else on Linux that is any more native. -- Greg
2011/9/14 Greg Ewing <greg.ewing@canterbury.ac.nz>
http://arstechnica.com/microsoft/news/2011/06/windows-8-for-software-develop... ;)
Python for .NET is a GREAT project which opens up a new world for Windows developers which want to start playing around with things like Silverlight, WPF, WCF, etc.. It's a tiny, but very useful project . Regards, Cesare
On Mon, Sep 12, 2011 at 20:56, Massimo Di Pierro <massimo.dipierro@gmail.com> wrote:
Just a question. What is the reason the win32 extensions are shipped separately? Is it a licensing issue or is there another reason?
It's certainly a mature project having been around for quite some time, and has also provided Python 3 support since the beginning. It's also a project for which there is no replacement, outside of hand-writing extension modules to expose the APIs you need, and it has given many developers access to the Windows APIs from the ease of a few simple imports. For those reasons, I think it's a great candidate for inclusion. There are negatives I see to inclusion, mainly the sheer size at 213K SLOC [0] (CPython is 713K). We're currently mulling over the inclusion of a new regular expression library which clocks in well below that at 28K, but it's potentially above the level at which anyone could provide a thorough review and gain an understanding, while simultaneously reducing the bus factor. While Mark is a respected member of the community and has already contributed directly to CPython, we should be careful to include something so large. I may be missing something due to the fragmented web presence, but documentation could be a challenge, although I remember some form of documentation being available on the ActiveState. Perhaps that could be converted to reStructuredText, or that might just have to start over. Maybe I'll seem crazy, but I think if we are to include this, the "py" prefix of the name would have to go. In fact, moving forward with this, even "win32" is probably a less than appropriate name, as Microsoft has moved to "Windows API" some time ago, which "more accurately reflects its roots in 16-bit Windows and its support on 64-bit Windows" [1]. I don't know the track record of stdlib inclusions and name changes, but I feel like this should be called "windows". Summary: although my negative talk outweighs the dinky positive paragraph, I think it's something worth looking into if Mark is on board with it. [0] generated using David A. Wheeler's SLOCCount. [1] http://en.wikipedia.org/wiki/Windows_API
Brian Curtin wrote:
The ActiveState docs seem to be just html versions of the docs distributed with the package, from what I've seen. IMO, the docs would need considerable work to bring them up to stdlib standards -- they're rather sketchy and incomplete in many areas. The package itself could also do with an overhaul. A lot of stuff seems to be wrapped twice in different ways, once in win32api and again in win32gui. -- Greg
Massimo Di Pierro <massimo.dipierro@gmail.com> writes:
Just a question. What is the reason the win32 extensions are shipped separately?
This might better be asked on the developers's forum; this forum is for discussing changes to Python.
Is it a licensing issue or is there another reason?
Here is a message to consider for information about this issue <URL:http://bugs.python.org/issue4954#msg85994>. -- \ “I think Western civilization is more enlightened precisely | `\ because we have learned how to ignore our religious leaders.” | _o__) —Bill Maher, 2003 | Ben Finney
On Tue, Sep 13, 2011 at 1:22 PM, Ben Finney <ben+python@benfinney.id.au> wrote:
'Why is it so?' questions are perfectly reasonable fodder for python-ideas (since they're usually a precursor to "let's do it differently"). Part of the reason this list exists is so misunderstandings of why Python is the way it is can be clarified here without generating traffic on the main development list.
I'm not sure why you linked that - it's about the need to use Visual Studio to safely build C extensions on Windows, not about why the CPython Windows installer doesn't bundle pywin32 the way ActiveState (and, IIRC, Enthought) do. The Python 3 series defines a stable ABI (PEP 384) that eliminates that restriction. As far as the original question goes, Mark Hammond would be the person in the best position to answer that. I don't know much about how pywin32 development works, and I'm not sure any of the other core devs do, either. The 'pywin32' web presence is fragmented enough that it isn't easy to find out more. (The SF project pages are at http://sourceforge.net/projects/pywin32/ and there seems to be some discussion at http://mail.python.org/mailman/listinfo/python-win32, but there's all sorts of stale information floating around which means that Google doesn't help much, either) Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Mon, Sep 12, 2011 at 9:26 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:
(Of course, for some folks python-ideas is the only list they read. :-) Regarding the original question, it's definitely not a licensing issue. Mark originally intended for pywin32 to be merged back into core Python, and I recall looking at this option seriously. I believe it was not a single issue that held it back, but a combination of factors: sheer size, coding style, robustness of the code (you can definitely cause crashes by passing bad arguments to pywin32 code), the dependency on a specific platform and compiler, the fact that no other core developer knew the codebase, and the different development speeds of core Python and pywin32. There may also have been some qualms about who was to build the installer. In the end we compromised: the core Python distro does not include pywin32all, but the download instructions contain a recommendation. For example, the Python 2.2 download page (http://www.python.org/download/releases/2.2/) says: "Windows users may also be interested in Mark Hammond's _win32all_, a collection of Windows-specific extensions including COM support and Pythonwin, an IDE built using Windows components." I don't know why that was dropped from the main release page for 2.3 and later; the same recommendation is still found on http://www.python.org/download/windows/ which is linked from a tab labeled "Windows" on all release pages. I assume that the development speed on pywin32 has slowed down to the point where we could consider including it in the core Windows installer. But I'm not sure if the logistics of building and testing the installer easily support this. There's also the impression (possibly wrong) that pywin32/win32all is somewhat dated, and hasn't changed much since the glory days of Windows 98. But actual developers using Python on Windows should be the judge of that. -- --Guido van Rossum (python.org/~guido)
Guido van Rossum wrote:
I think that's mainly because the thing it's wrapping -- the win32 api -- is somewhat dated, and hasn't changed much since the glory days of Windows 98. :-) By today's standards, the traditional win32 gui api is hopelessly cruddy. Unfortunately, the only efforts on Microsoft's part to replace it with something better seem to be taking place in the .NET world. As things stand, this places them out of the easy reach of Python. Adding something to the stdlib enabling Python to call .NET libraries would open up considerable new opportunities. Maybe it could be based on this: http://pythonnet.sourceforge.net/ -- Greg
On Tue, Sep 13, 2011 at 20:08, Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
Could we skip inclusion the win32gui stuff? We'd be including something which has been surpassed by WinForms, which itself has (mostly?) been surpassed by WPF, and soon enough we'll have Metro...on top of the fact that we'd be introducing a second way to do GUI work alongside Tkinter.
Do we really need to be encouraging use of Windows APIs in Python? Given the greater user base of Windows, is there a danger this could encourage the littering of Windows-only "workarounds" in many projects? "Well Python doesn't ship with a usable GUI toolkit (hi tk), but it does ship with Win32"->"Everyone uses Windows anyway, lets make a Win32 interface". Just a thought. On Wed, Sep 14, 2011 at 11:22 AM, Brian Curtin <brian.curtin@gmail.com> wrote:
On Tue, Sep 13, 2011 at 21:28, Matt Joiner <anacrolix@gmail.com> wrote:
Do we really need to be encouraging use of Windows APIs in Python?
I don't think we're encouraging anything, nor do I think we need to. People have already been doing so for quite some time - it's a fact of life. If I want to write a tool which uses Windows' ReadDirectoryChangesW API, how do I do that today? I either write a C extension (which I've done), or I use pywin32. I must be missing something, because your question comes off as saying "don't solve that problem".
I don't think the inclusion of this package is going to enlighten people on the ability to make platform specific workarounds in their code. They've already been doing this with pywin32 or extension modules where necessary, and I don't think that's a such bad thing. Obviously it's great when Python provides a way to solve a cross-platform problem with one solution, e.g., listing directory contents, but it's not all sunshine and rainbows. Sometimes working with those contents requires a platform specific operation.
On Wed, Sep 14, 2011 at 1:19 PM, Massimo Di Pierro <massimo.dipierro@gmail.com> wrote:
For me the only reason win32 is important is to implement a cross-platform file locking. I did not mean to propose web32 should be included but a portable file locking api would be useful.
If Windows developers wanted to work with Mark Hammond to figure out and systematically extract a core subset of stable pywin32 functionality potentially suitable for inclusion in the standard library, that may not be a bad thing (there's currently already duplication between the two, since the stdlib needs aspects of the win32 API to implement modules like subprocess and multiprocessing, but in those cases the pywin32 version is almost always more feature complete). The stdlib version could evolve as the standard library does, while pywin32 could move a bit quicker in responding to releases of new versions of Windows. However, CPython+pywin32 suffers from the curse of being a "good enough" solution most of the time (especially if you start with a bundled installer that takes care of finding a suitable version of pywin32 for the version of CPython being installed). Personally, I do think this idea has potential to be a valuable project, but I also think the same could be said just for helping pywin32 consolidate its web presence and promote itself more clearly. Currently, a Google search for pywin32 gives you: ~4 hits on the SourceForge project. This is *correct*, but SF in general (and currently pywin32 in particular) is organised for existing developers, not for users or potential new developers (finding the latest release and being sure it *is* the latest release is not trivial - more on this below). The next hit is on Mark's old starship page - that's ancient and hasn't been used for pywin32 downloads in years Next we have the PyPI page, which appears to be a couple of releases out of date (SF has 216, PyPI has 214) Then we have two copies of the PyPI documentation, one hosted by ActiveState (as part of the ActivePython 2.7 docs), the other by Tim Golden. Assuming Mark was happy to go along with the idea, it would be great to see some real content at http://pywin32.sourceforge.net/ instead of the current placeholder page. For example: - quick description of the project and how it can really help with Windows-specific development (and general Windows compatibility) - link directly to latest download file on Sourceforge - link to PyPI entry - link to the user mailing list (python-win32@python.org, I believe) - basic instructions on how to get involved as a developer As an even larger task, it would be great to see some Sphinx docs for Pywin32 that provided an overview of the various modules included in the package, and references out to the relevant MS documentation (as well as to the automatically generated documentation for pywin32 itself). Regards, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
I would help but I do not feel competent as I am not a windows user. For portability reasons I have had a need for: win32con.LOCKFILE_EXCLUSIVE_LOCK win32con.LOCKFILE_FAIL_IMMEDIATELY win32file._get_osfhandle win32file.LockFileEx pywintypes.OVERLAPPED() Although I have not used this much, the ability to talk to windows app is also useful: import win32com.client xl = win32com.client.Dispatch("Excel.Application") Massimo On Sep 13, 2011, at 11:12 PM, Nick Coghlan wrote:
Well... ReadDirectoryChangesW is present in pyfilesystem, that Nick mentioned in another thread. In fairness you shouldn't expose this without exposing inotify for Linux, and whatever nasty equivalents are available on other systems. pywin32 gives you full access to the Windows kernel interface. The same functionality is not bundled in the standard library for Linux. To use Massimo's example regarding file locking, just this morning I had to write a ctypes wrapper around struct flock for this purpose because the fcntl module is only a partial implementation. If the full Windows API is made available, you might as well complete some of those half-done modules now that the single biggest sore thumb (Windows) for OS interfaces will be laid bare. Python is well respected for its cross platform support. Making bindings available in both cross platform and native forms will greatly improve uptake of Python. My thoughts are that more effort should be made to completely expose Unix/Linux/Mac interfaces before (or simultaneously) with making the entire Windows API available. On Wed, Sep 14, 2011 at 1:00 PM, Brian Curtin <brian.curtin@gmail.com> wrote:
On Tue, Sep 13, 2011 at 23:13, Matt Joiner <anacrolix@gmail.com> wrote:
pywin32 gives you full access to the Windows kernel interface. The same functionality is not bundled in the standard library for Linux.
Correct me if I'm wrong, but it doesn't exist.
Mark or someone could probably answer this question in a second, but I've tried to find a date for when pywin32 was first released, which is kind of tough. win32all build 135 added Python 2.0 support, which was released in October 2000, so I suspect that build occurred close to that time. There are 29 releases listed before that one on http://python.net/crew/mhammond/win32/RecentChangeHistory.html (and potentially more elsewhere, as the list only goes to 106), all going back to the Python 1.x times. Do we really need to hold back a 10+ year old project because no one thought to do the same thing for other platforms? I don't disagree that having bindings for all popular platforms is a good thing, but we'll be on Python 5 by the time we can wrangle up people to write all of that code, maintain it, and watch it mature while helping it find wide reaching adoption. Mark released the book "Python Programming on Win32" in January 2000, which I still have on my desk despite it barely surviving a flooded basement, and it's almost all based on this package. It was mature enough even then to write most of a 600+ page book with, which puts it in a very small camp of projects.
2011/9/14 Matt Joiner <anacrolix@gmail.com>
We already have platform-specific modules on stdlib. ;) Have you written any interactive command-line interpreter in Python? It's great if you are using an Unix-like o.s., since the readline module can be used, but Windows programmers can't do the same. -_- As a programmer, I use Python to help on solving my problems, whatever the platform I was using to develop for. If I need to make a Windows-only project, there's nothing that Python can do to stop me. But I'll definitely appreciate it, if it can make my life easier on doing this. Regards, Cesare
Cesare Di Mauro wrote:
I agree, and it'll be interesting to know if encouraging the use of Linux or OS X APIs raises such "questions" as well...
We already have reasonably good third-party wrappers for GUI facilities on the other platforms -- PyObjC on MacOSX, and pygtk on Linux. We don't have anything equivalent for recent Windows technologies, though. -- Greg
Georg Brandl wrote:
Gtk isn't any more a platform facility than Qt is.
It's the closest thing we have to a platform-native GUI facility in the Linux world, though. It's not the *only* one -- there are others, such as KDE. But if you work in a Gnome environment, all the system stuff is built on it, and it defines the look and feel that you expect apps to have. So it occupies much the same place that Cocoa does on MacOSX. -- Greg
Well technically not. KDE mostly supplements Qt, A few objects here and there make use of some Qt features. The gobject, glib combination are bound up in numerous low level system services and supplementary libraries that have nothing to do do with GUIs, even I think on a KDE system. That said, if system GUI capable APIs are to be exposed on the standard library, those should be Win32, Cocoa, and GTK+. On Sep 16, 2011 2:11 PM, "Georg Brandl" <g.brandl@gmx.net> wrote:
On Fri, Sep 16, 2011 at 6:25 PM, Matt Joiner <anacrolix@gmail.com> wrote:
The freedesktop.org standard APIs are a mix of services that originated in various parts of the Linux software stack. Some originate from x.org, some from Gnome/Gtk, some from KDE/Qt. I've yet to see a Gtk based app that feels native on KDE, mainly because the Gtk file dialogs are so atrocious and fd.org has yet to standardise things to the point where the apps designed for each environment can invoke each other's system dialogs. Regardless, there are going to be limits to what the standard library can realistically keep up to date with when it comes to platform-specific support. The cutting edge for the various platforms is always going to require third party libraries. It may be that there are stable subsets of functionality that *could* be included in the standard library (there are certainly plenty of *nix specific wrappers for system APIs), but the existence of those are predicated on interested parties stepping up to maintain them in accordance with python-dev policies. And really, it doesn't gain all that much - if you're targeting a specific platform, you're probably going to want the up-to-date platform specific libraries *anyway*. If you don't, then the cross-platform stuff in the core will likely suffice. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
Am 16.09.2011 10:25, schrieb Matt Joiner:
Well technically not. KDE mostly supplements Qt, A few objects here and there make use of some Qt features.
This is not quite true: just grep for "Q" through the KDE headers. Most objects there are QObjects, and the basic signal-slot mechanism comes from Qt, as well. But I will stop here, since it's not the point of the discussion. It's just not true that Gtk is "the" blessed toolkit for X11. (Just like Vim is not the one true editor :) Georg
2011/9/16 Matt Joiner <anacrolix@gmail.com>
And .NET too, since it's a Windows technology which you'll find on any Windows >= Vista (but also installable on XP). It doesn't mean that we necessarily need to wrap every single win32 and/or .NET API into a Python package on the stdlib. ctypes is useful to access whatever you want (win32 and any DLL, OS X dynamic libraries, Linux .so). Python for .NET can do the same for .NET, and is small enough to be made available on the stdlib. I think that something similar can be provided for OS X and Linux through Mono. Regards, Cesare
On 17 September 2011 07:30, Cesare Di Mauro <cesare.di.mauro@gmail.com>wrote:
Python.NET is basically unmaintained, and requires very specialised knowledge to develop. I don't think it's in a position to move it into the standard library. For accessing .NET from Python IronPython is a much better alternative (with caveats about the use of C extensions that apply to any of the alternative implementations). All the best, Michael
-- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html
On 22 September 2011 01:12, Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
That in itself doesn't make adding Python.NET to the standard library feasible... Michael
-- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html
Georg Brandl wrote:
And if you work in a KDE environment, all its stuff is built on Qt. I really don't see how the two are on different levels.
I'm not necessarily saying that they are, only that gtk as it exists on Linux is at no *higher* a level than Cocoa or the win32 api are on their respective platforms, and that there is nothing else on Linux that is any more native. -- Greg
2011/9/14 Greg Ewing <greg.ewing@canterbury.ac.nz>
http://arstechnica.com/microsoft/news/2011/06/windows-8-for-software-develop... ;)
Python for .NET is a GREAT project which opens up a new world for Windows developers which want to start playing around with things like Silverlight, WPF, WCF, etc.. It's a tiny, but very useful project . Regards, Cesare
On Mon, Sep 12, 2011 at 20:56, Massimo Di Pierro <massimo.dipierro@gmail.com> wrote:
Just a question. What is the reason the win32 extensions are shipped separately? Is it a licensing issue or is there another reason?
It's certainly a mature project having been around for quite some time, and has also provided Python 3 support since the beginning. It's also a project for which there is no replacement, outside of hand-writing extension modules to expose the APIs you need, and it has given many developers access to the Windows APIs from the ease of a few simple imports. For those reasons, I think it's a great candidate for inclusion. There are negatives I see to inclusion, mainly the sheer size at 213K SLOC [0] (CPython is 713K). We're currently mulling over the inclusion of a new regular expression library which clocks in well below that at 28K, but it's potentially above the level at which anyone could provide a thorough review and gain an understanding, while simultaneously reducing the bus factor. While Mark is a respected member of the community and has already contributed directly to CPython, we should be careful to include something so large. I may be missing something due to the fragmented web presence, but documentation could be a challenge, although I remember some form of documentation being available on the ActiveState. Perhaps that could be converted to reStructuredText, or that might just have to start over. Maybe I'll seem crazy, but I think if we are to include this, the "py" prefix of the name would have to go. In fact, moving forward with this, even "win32" is probably a less than appropriate name, as Microsoft has moved to "Windows API" some time ago, which "more accurately reflects its roots in 16-bit Windows and its support on 64-bit Windows" [1]. I don't know the track record of stdlib inclusions and name changes, but I feel like this should be called "windows". Summary: although my negative talk outweighs the dinky positive paragraph, I think it's something worth looking into if Mark is on board with it. [0] generated using David A. Wheeler's SLOCCount. [1] http://en.wikipedia.org/wiki/Windows_API
Brian Curtin wrote:
The ActiveState docs seem to be just html versions of the docs distributed with the package, from what I've seen. IMO, the docs would need considerable work to bring them up to stdlib standards -- they're rather sketchy and incomplete in many areas. The package itself could also do with an overhaul. A lot of stuff seems to be wrapped twice in different ways, once in win32api and again in win32gui. -- Greg
participants (11)
-
Ben Finney -
Brian Curtin -
Cesare Di Mauro -
David Townshend -
Georg Brandl -
Greg Ewing -
Guido van Rossum -
Massimo Di Pierro -
Matt Joiner -
Michael Foord -
Nick Coghlan