What happened to the CurrentVersion registry entry documented at
http://www.python.org/windows/python/registry.html
AFAICT, even the python15.wse file did not fill a value in this
entry (perhaps I'm misinterpreting the wse file, though).
So was this ever used? Why is it documented, and who
Suppose we run script.py while playground/ is the current directory.
I'm using 2.4.2 here, but doubt it matters much. No Python-related
envars are set.
Windows (and the PIL and pywin32 extensions are installed here):
C:\playground\python24\python.exe someother\script.py
Michiel wrote:
Guido van Rossum wrote:
On 11/9/05, Michiel Jan Laurens de Hoon
[EMAIL PROTECTED] wrote:
My application doesn't need a toolkit at all. My problem is that because
of Tkinter being the standard Python toolkit, we cannot have a decent
event loop in Python. So this is the
release. The main reason why I changed the import behavior was
pythonservice.exe from the win32 extensions. pythonservice.exe imports
the module that contains the service class, but because
pythonservice.exe doesn't run in optimized mode, it will only import a
.py or a .pyc file, not a .pyo
Shane:
Vinay Sajip wrote:
I'd be interested in your approach to solve this.
To be compatible with an external tool like logrotate, all a daemon
needs to do is close and reopen log files at about the same time log
rotation happens. To handle this use case, I suggest the logging module
Guido:
What a mess. :-(
WindowsError should have used a different name for the Windows-native
error code, so we could have defined both separately without
confusion.
Is it too late to change WindowsError in that way?
I guess too late is purely a judgement call about breaking existing code.
Sorry for the slightly off-topic post, but I thought it of interest that
Brendan Eich (the father of javascript) has blogged about the future of
js, and specifically how he will borrow from Python for iteration,
generators, and comprehensions and more generally why he is standing on
Pythons
Roger on python-win32 had an answer which works for me:
[Roger Upole wrote]
WMI can list sound devices.
import win32com.client
wmi=win32com.client.GetObject('winmgmts:')
scs=wmi.InstancesOf('win32_sounddevice')
for sc in scs:
print
So PythonWin needs to be installed on a Windows buildbot slave, right?
FWIW, we are having reasonable success with buildbot service packaged as a
py2exe application - just unzip into a directory and go! This has the
primary advantage (to me!) of not using the Python installed on the box,
Tim:
[Martin]
on XP SP2: test_mailbox fails to
me, with permission denied in some (random) test. I believe this
is due to Tortoise SVN: test_mailbox creates a few directories,
then Tortoise detects them (thanks to file change notifications)
and tries to walk them, to find out whether
I wrote:
Bob writes:
Ack - sorry about that - the HTML mail confused me :) It was Brett, of
course.
Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
Guido writes:
As Phillip understood, I meant the environment to include the
filesystem (and on Windows, the registry -- in fact, Python on Windows
*has* exactly such a mechanism in the registry, although I believe
it's rarely used these days -- it was done by Mark Hammond to support
COM
Has anyone heard the Python+XUL community cry I'm not dead
yet! or are
they really dead? I haven't seen mentions of new work in these areas
lately. XUL in general seems to have died (so many broken
links on XUL
pages). Was this just a fad? If not, and if there's some
really useful
of
Please add my -1 to the chorus here, for the same reasons already expressed.
Cheers,
Mark
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
]On Behalf
Of Jim Jewett
Sent: Monday, 30 April 2007 1:29 PM
To: Python 3000; Python Dev
Subject: [Python-Dev] PEP 30XZ:
Hi all,
I hope the cross-post is appropriate.
I've started playing with getting the pywin32 extensions building under
the AMD64 architecture. I started building with Visual Studio 8 (it was
what I had handy) and I struck a few issues relating to the compiler version
that I thought worth
Hi Martin,
You are likely doing something wrong:
a) I assume it's VS 7.1 (i.e. VS.NET 2003); VS 2002 is not supported
at all
b) you probably didn't install vsextcomp, but you should.
In fact, you don't need all of it, but you do need the cl.exe and
link.exe wrappers it comes with -
Kristján Valur Jónsson quoting me:
hrm - as above, I'm more concerned with the definition of
WCHAR - which
means my problem is related more to the Platform SDK version rather
than the
compiler. This is unfortunate - on one hand we do consider
'platform=Windows API', and WCHAR is very
Hi Kristján,
First of all, I have put some work into pcbuild8 recently and it works
well.
It does! There are a few issues though, notably with distutils (and as
mentioned before, any other tools what may assume PCBuild - see below)
You quoting Martin:
I don't find the need to have separate
Hi Marc-Andre,
+1 from me.
If think this is simply a bug introduced with the UCS4 patches in
Python 2.2.
unicodeobject.h already has this code:
#ifndef PY_UNICODE_TYPE
/* Windows has a usable wchar_t type (unless we're using UCS-4) */
# if defined(MS_WIN32) Py_UNICODE_SIZE == 2
#
Hi Martin,
I'm using the full-blown VS.NET 2003, as given to a number
of python-dev
people by Microsoft a number of years ago. This appears to
come with the
SDK and a 64bit compiler.
Not sure what it makes it appear to you that way - it doesn't. VS.NET
2003 is x86 only
Yes - I was
However, I think people ask much too often for a debugging build;
in many cases, they could work happily with a release build that
supports debugging. Depending on the problem you try to solve, you
may or may not need debug information for pythonxy.dll as well,
or just for your extension
Someone mentioned the idea to have a bat file do it. I like
that idea. There is already a build.bat file which will
build whatever configuration you choose (platform and
configuration). Extending it to subsequently copy the
resulting binaries up one level is easy. Perhaps this is an
Very well, leaving linux aside, I don't see why this:
/win32mount/trunk/PCbuild/
/x64mount/trunk/PCbuild/
Is any different from
/winmount/trunk/PCBuild/win32
/winmount/trunk/PCBuild/x64
In the former case, assuming python is running from the 'trunk' directory,
all architectures know how
Martin v. Löwis wrote:
I use this patch in ActivePython to get distutils to find
the correct
PCbuild dir (see attached).
Would you like to commit this to 2.6? (or perhaps 2.5 even?)
Sure, if others think it is a good thing. Will do tomorrow
unless I hear
a -1 before then.
I'm not
From: Jamie Kirkpatrick [mailto:[EMAIL PROTECTED]
Sent: Wednesday, 23 May 2007 5:16 AM
I have a set of extensions that use SWIG to wrap my own C++ library. This
library, on a
day-to-day basis is built against VS8 since the rest of our product suite
is. Right now
I have no way to work with
All,
I wanted to pass this one around before opening an issue on it.
When running the unit test for popen via rt.bat (in PCBuild8),
I received the following error:
=== BEGIN ERROR ===
C:\Documents and
Settings\joe\Desktop\Development\Python\trunk\PCbuild8rt test_popen
Deleting .pyc/.pyo
My apologies for being a day late, got working on some other things.
So here's the scoop as it relates to the issue at hand:
- If you run rt.bat from the trunk as-is and place it in a path that
contains an empty space, you receive the error outlined in
resultwithspace.txt.
- If you run
My apologies for being a day late, got working on some other things.
So here's the scoop as it relates to the issue at hand:
Something else I meant to mention: your problem is that the test suite
fails in some circumstances, but these circumstances are not met for most
core developers or when
After installing the x64 version of Python 2.5.1 via the MSI file on
python.org, I noticed most of the registry keys are missing. Further
investigation shows they aren't actually missing, but have simply been
virtualized, so they actually appear under the Wow6432Node key.
This Wow6432Node key is
Per the requirements documented at
http://msdn2.microsoft.com/En-US/library/aa372396.aspx, the behavior
you describe is expected for a 32-bit installer.
Agreed - but unless I'm missing something, this release is not expected to
be a 32bit installer.
(To install files and
registry to 64-bit
On Friday, 13 July 2007, Michael Urman wrote:
Furthermore only one architecture may be set in the template summary,
so an installer may be only one of i386, x64, and Intel64 (although
the latter are assumed to also be able to run i386 binaries).
I suspect I'm still missing something here.
Martin quoting me:
Yes - that is a bit of a shame, as having 32bit components
would allow more flexibility (eg, allow a 64bit install of
Python to work with an IIS configured for 32bit extensions),
but that's something we can deal with later if necessary.
Can you elaborate?
As you
Martin:
Assuming this is the right file, the cause of the behavior Mark
reported is pretty clear. While the template summary is indeed x64,
the attributes on the registry components are all 4 instead of 256 |
4, so they are placed in the 32-bit reflected registry. I don't know
if this is
Hi Martin,
I found the same thing, and put a corrected installer at
http://www.dcl.hpi.uni-potsdam.de/home/loewis/python-2.5.1.amd64.msi
Is there any intention to update the msi at python.org? Alternatively, can
I point people at the above file? I've a .msi created by bdist_msi that
works
Now I finally found that my problem are these two lines in
subprocess.py:
if stdin is None and stdout is None and stderr is None:
return (None, None, None, None, None, None)
These lines add an interesting quirk: if I explicitly specify any
single
C:\1.py
hStdOut: 0007
Something
C:\1.py1.txt
hStdOut: 0004
(1.txt file is now completely empty, i.e. hStdOut is invalid)
Hmm, now I see that maybe that's where I was wrong. When I used
`python 1.py1.txt' it suddenly started working as expected.
I can't figure out how to build a Windows package for ssl-1.1.tar.gz,
and probably don't have the tools to do it anyway. I presume that
both a Windows machine and Visual Studio (because there's a C
extension) is required?
Anyone out there who's interested in the challenge?
It's at
* find_ssl() is along way from working on Windows. Python itself
uses magic
to locate an SSL directory in the main Python directory's parent. On
my
system, this is c:\src\openssl-0.9.7e, but obviously that could be
almost
anywhere, and with almost any name. See PCBuild\build_ssl.py
You don't need VS and mingw binary installers, though - the mingw ones
will work for any Python (ignoring specialised custom builds, and
anyone doing one of them is probably capable of building the ssl
module!).
Why I appreciate your points about building the extension with free tools,
So, the question is what we should do?:
1. Rely on the kernel32 function and behaves like it says?
2. Return a fixed response for this special file nul?
Personally, I prefer the first one, but it changed the semantic of
os.path.exists(nul) (but this semantic is not clear, as we get
* Are the directories for Windows, Mac and Unix fine?
Regarding Windows, I personally think its OK (but I also personally think
the status-quo is OK too). As has already been mentioned in this thread,
Windows actually provides an API you can call to determine various well
known folders. I
Isn't SHGetSpecialFolderPath() XP and newer only?
MSDN documents:
Minimum operating systems Windows 2000, Windows NT 4.0 with Internet
Explorer 4.0, Windows 98, Windows 95 with Internet Explorer 4.0
The patch is available at
http://bugs.python.org/issue1763. Maybe you have some time to review
Hi Martin,
Way back on Monday, 21 May 2007, you wrote:
This is an issue to be discussed for Python 2.6. I'm personally
hesitant to have the official build infrastructure deviate
from the layout that has been in-use for so many years, as a lot
of things depend on it.
I don't find the
Jeroen Ruigrok van der Werven:
-On [20080224 19:57], Martin v. Lwis ([EMAIL PROTECTED]) wrote:
I can continue to provide Windows binaries if desired.
If need be, I can help testing the build infrastructure since I have
access
to various releases of Visual Studio as well.
Me too - I still
Martin v. Löwis wrote:
I've looked at it, and I seriously doubt that. In WiX, you need to
specify a fixed file list (perhaps with wildcards; I'm unsure). This
will be tricky for Python, where the list of files to be installed
changes all the time.
You *need* to have a turing-complete
On 8/02/2009 10:21 AM, Antoine Pitrou wrote:
Mark Hammondskippy.hammondat gmail.com writes:
I'm not sure if the following is a bug I should report or simply an
artifact of the implementation and/or simply the way things work on py3k:
[...]
It's a bug.
http://bugs.python.org/issue5182
On 25/03/2009 6:51 AM, Martin v. Löwis wrote:
Mike Driscoll did some work providing Windows installers for various
Python packages and extension modules, and people were amused that he
provided executable installers for pure Python libraries. But I saw that
as a sensible decision, since it meant
On 25/03/2009 7:34 AM, Martin v. Löwis wrote:
I don't quite remember the -n flag, but I believe that Kristjan
just removed all that stuff, ie. there is now no way to block
CRT assertions anymore.
I
wasn't paying close attention, so maybe there's some other mechanism
in place at this point?
On 25/03/2009 10:05 AM, David Bolen wrote:
Kristján Valur Jónssonkrist...@ccpgames.com writes:
Now, I know that this msvc behaviour can be disabled, but it was
decided that it was not appropriate to meddle with runtime flags of
the whole process for python.
I must have missed that
On 25/03/2009 7:58 PM, David Bolen wrote:
Mark Hammondskippy.hamm...@gmail.com writes:
The issue was that Python unconditionally changed the behaviour of the
CRT, not only during the test suite.
Hmm... I was more or less referring to the state of the py3k tree as
of, say, r57823 back in
I'm going to poke my contacts at Microsoft and ask them if there is a way to
disable popups like this for a process that runs unattended and/or is running
as a windows service.
There is, and Curt pointed out one strategy for achieving this without
losing the checks it provides...
Curt's
On 28/03/2009 7:49 AM, gl...@divmod.com wrote:
Perhaps bdist_wininst/_msi could be donated to the
py2exe project if they would be willing to maintain it, and the new
project for _deb and _rpm could be called py2packman or something.
As mentioned, it isn't really a natural fit - but regardless,
On 6/04/2009 12:13 AM, Dirkjan Ochtman wrote:
I have a stab at an author map at http://dirkjan.ochtman.nl/author-map.
Could use some review, but it seems like a good start.
Just to be clear, what input would you like on that map?
I'm listed twice:
mark.hammond = Mark Hammond skippy.hamm
[Dropping email sig]
On 11/04/2009 1:06 PM, Martin v. Löwis wrote:
However, I really think that this question cannot be answered by
reading the RFC. It should be answered by verifying how people use
the json library in 2.x.
In the absence of anything more formal, here are 2 anecdotes:
* The
On 11/04/2009 6:12 PM, Antoine Pitrou wrote:
Martin v. Löwismartinat v.loewis.de writes:
Not sure whether it would be *significantly* faster, but yes, Bob wrote
an accelerator for parsing out of a byte string to make it really fast;
IIRC, he claims that it is faster than pickling.
Isn't
Larry Hastings wrote:
Counting the votes for http://bugs.python.org/issue5799 :
+1 from Mark Hammond (via private mail)
+1 from Paul Moore (via the tracker)
+1 from Tim Golden (in Python-ideas, though what he literally said
was I'm up for it)
+1 from Michael Foord
+1 from
Eric Smith wrote:
Mark: I've reviewed this and it looks okay to me.
Thanks Eric - I've now applied that patch. As you mentioned in a
followup to the bug:
| Thanks for looking at this, Mark. If we could only assign issues to
| Python 3.2 and 3.3 to change the pending deprecation warning to
Paul Moore wrote:
2009/6/5 Nick Coghlan ncogh...@gmail.com:
Dirkjan Ochtman wrote:
Essentially, pcbuild.sln is a binary file, and should be treated as
such. Maybe it's an error in the Subversion setup that it's treated as
text at all...
Yes, it certainly seems that way.
Except it isn't a
On 3/07/2009 6:42 AM, Dirkjan Ochtman wrote:
In response to some rumblings on python-committers and just to request
more feedback, a progress report. I know it's long, I've tried to put
to keep it concise and chunked, though.
Although this has come up in the past, I don't recall a resolution.
On 3/07/2009 9:28 PM, Dirkjan Ochtman wrote:
On Fri, Jul 3, 2009 at 01:01, Mark Hammondskippy.hamm...@gmail.com wrote:
Although this has come up in the past, I don't recall a resolution.
What is your plan to handle svn:eol-style? We have some files in the tree
which need that support and
On 4/07/2009 12:04 AM, Nick Coghlan wrote:
However, I expect that would still be painful to work with for Windows
developers, even if it prevented any line ending problems from making
their way into the main repository. I believe that is where the
win32text extensions can help. Looking at the
On 3/07/2009 11:43 PM, Dirkjan Ochtman wrote:
On Fri, Jul 3, 2009 at 15:31, Mark Hammondmhamm...@skippinet.com.au wrote:
So we must work without effective EOL support? I fear we will end up like
the mozilla hg repo with some files in windows line endings and some with
linux. While my editing
On 3/07/2009 11:43 PM, Dirkjan Ochtman wrote:
As long as the difference between \r\n- and \n-based files is clear
and can be reasoned about, I don't see why having some of both (I'm
assuming an overwhelming majority will have one, and only a few the
other) is a big problem. But feel free to
On 4/07/2009 11:20 AM, Nick Coghlan wrote:
I didn't realise Mercurial didn't have a way for a repository to provide
versioned extension settings, but in this case I think using our own
server side hook can deal with the problem (either adding it to the
existing whitespace hook that checks for
On 4/07/2009 12:30 PM, Nick Coghlan wrote:
...
I think there needs to be a solid answer in place for these use cases
before the actual migration to Mercurial takes place. A hand-waving use
win32text isn't enough - it needs to be use win32text with these exact
settings (with server side hook
Sorry Dirkjan - I just noticed I didn't CC you on this mail originally.
I'm wondering if you have any more thoughts on these EOL issues and if
there is anything I can do to help?
Cheers,
Mark
On 4/07/2009 2:03 PM, Mark Hammond wrote:
On 4/07/2009 12:30 PM, Nick Coghlan wrote:
...
I think
On 4/08/2009 7:20 PM, Nick Coghlan wrote:
Dirkjan Ochtman wrote:
* commit hooks be implemented to enforce this - but this should not be
necessary if the above was implemented and socially enforced.
You seem to advocate a two-step approach: enforce line endings through
win32text, catch any
On 5/08/2009 3:56 PM, Ben Finney wrote:
Mark Hammondmhamm...@skippinet.com.au writes:
Let's say I make a branch of the hg repo, myself and a few others work
on it committing as we go, then attempt to merge back upstream. Let's
say some of the early commits on that clone introduced bad line
On 5/08/2009 4:50 PM, Ben Finney wrote:
Mark Hammondskippy.hamm...@gmail.com writes:
On 5/08/2009 3:56 PM, Ben Finney wrote:
Mark Hammondmhamm...@skippinet.com.au writes:
Let's say I make a branch of the hg repo, myself and a few others work
on it committing as we go, then attempt to
On 5/08/2009 5:35 PM, Martin v. Löwis wrote:
Now, the specific outcome of the process means that more work needs to
be done. So we have a *second* PEP, and we have a lack of volunteers
that help implementing it. The second PEP hasn't been approved yet
(as it isn't complete, yet), so migration
On 5/08/2009 6:00 PM, Ben Finney wrote:
Mark Hammondskippy.hamm...@gmail.com writes:
As already mentioned in this thread, a capability similar to what svn
or cvs offers would be sufficient.
That capability presented by centralised VCSen is entirely dependent on
the fact that they *are*
On 5/08/2009 6:25 PM, Dirkjan Ochtman wrote:
On Wed, Aug 5, 2009 at 01:43, Mark Hammondmhamm...@skippinet.com.au wrote:
Thanks Nick; I didn't want to be the only one saying that. There is a fine
line between asserting reasonable requirements for Windows users and being
obstructionist and
On 5/08/2009 7:09 PM, Dirkjan Ochtman wrote:
I'm not sure how win32text will provide anything other than
performance degradation for non-Windows developers, but if there's
functionality to be had, I'm happy to mandate its use on every
platform.
I see two practical outcomes of such a mandate:
On 5/08/2009 8:04 PM, Paul Moore wrote:
2009/8/5 Martin v. Löwismar...@v.loewis.de:
With such a setup, using the hook would be truly optional on Unix,
as it only ever checks and never converts. So if you manage to mess
up, and don't have the hook installed on Unix, you lose when trying
to
On 5/08/2009 8:14 PM, Dirkjan Ochtman wrote:
endings. Typically, in my case, that was either Notepad2 (an awesomely
light-weight Notepad replacement) or Komodo (Edit). That solved all of
my issues, so I haven't had a need for win32text so far.
FWIW, I use komodo and scite as my primary
On 5/08/2009 9:28 PM, Dirkjan Ochtman wrote:
On Wed, Aug 5, 2009 at 13:19, Mark Hammondmhamm...@skippinet.com.au wrote:
Configuring on each clone would certainly be sub-optimal, so the proposal is
this configuration be stored in a versioned file in the repo.
Even if we do that, enabling hg
On 6/08/2009 12:28 AM, Stephen J. Turnbull wrote:
Mark Hammond writes:
I'm not sure what point you are trying to make, but I believe it *is*
possible for a solution to be found here which will keep Windows users
happy. I'm guessing you haven't had much practical experience
here is currently the win32text stuff.
Mark Hammond said he would work on this; Mark, when do you have time
for this? Then I could set apart some time for it as well.
I can make time, somewhat spasmodically, starting fairly soon. Might I
suggest that as a first task I can resurrect my old stale
[Adjusted the CCs...]
On 19/08/2009 8:21 AM, Dj Gilcrease wrote:
On Tue, Aug 18, 2009 at 2:12 AM, Martin v. Löwismar...@v.loewis.de wrote:
The second item is line conversion hooks. Dj Gilcrease has posted a
solution which he considers a hack himself. Mark Hammond has also
volunteered
On 22/08/2009 12:19 AM, Dirkjan Ochtman wrote:
On Fri, Aug 21, 2009 at 16:10, Dj Gilcreasedigitalx...@gmail.com wrote:
I like this, though maybe .hgextensions since it would contain
versioned rules and the actual required extension. The extra sub
directories are not really required IMHO, you
On 22/08/2009 12:10 AM, Dj Gilcrease wrote:
On Fri, Aug 21, 2009 at 1:16 AM, Mark Hammondskippy.hamm...@gmail.com wrote:
Maybe you can enumerate what you think needs to change in mercurial, then
once we have a plan in place it will be clearer who can do what.
The encode/decode hooks need to
On 22/08/2009 2:46 PM, Stephen J. Turnbull wrote:
Mark Hammond writes:
Something like ~/.hgrules having:
Surely you mean $PROJECTROOT/.hgrules?
Indeed.
[config] # or maybe [rules] ?
required_extensions = win32text, some_pydev_specific_extension
[extensions
On 22/08/2009 6:52 PM, Stephen J. Turnbull wrote:
Mark Hammond writes:
On 22/08/2009 2:46 PM, Stephen J. Turnbull wrote:
Possibly - although I would expect the existing section names be reused
when applied to a versioned file, I'd be more than happy for the hg guys
to declare
On 22/08/2009 7:09 PM, Martin v. Löwis wrote:
From my POV, this would be required in some form or another before such
a scheme could actually work. Without it we end up with an improved
win32text (good!)
I still think this would be actually bad.
Instead, a new extension should be written,
On 23/08/2009 5:25 PM, Martin v. Löwis wrote:
If this becomes seen as 'my' cause, I suspect it will run out of steam
very quickly. I truly hope python-dev, as a community, takes some
ownership of this issue
That certainly won't happen. python-dev, as a community, has never ever
taken
here is currently the win32text stuff.
Mark Hammond said he would work on this; Mark, when do you have time
for this? Then I could set apart some time for it as well.
Have stalled a bit on the fine-grained branch processing, hope to move
that forward tomorrow.
I'm afraid I've also stalled
On 30/08/2009 9:37 PM, Martin Geisler wrote:
Mark Hammondskippy.hamm...@gmail.com writes:
1) I've stalled on the 'none:' patch I promised to resurrect. While
doing this, I re-discovered that the tests for win32text appear to
check win32 line endings are used by win32text on *all* platforms,
+1 from me!
Mark
On 25/10/2011 9:57 AM, Victor Stinner wrote:
Hi,
I propose to raise Unicode errors if a filename cannot be decoded on Windows,
instead of creating a bogus filenames with questions marks. Because this change
is incompatible with Python 3.2, even if such filenames are unusable
On 29/10/2011 9:52 AM, Victor Stinner wrote:
Hi,
I am not more conviced that raising a UnicodeEncodeError on unencodable
characters is the right fix for the issue #13247. The problem with this
solution is that you have to wait until an user get a UnicodeEncodeError.
I have yet another
On 31/10/2011 8:39 AM, Victor Stinner wrote:
Le 29/10/2011 07:47, Mark Hammond a écrit :
When previously discussing this issue, I was under the impression that
the problem was unencodable bytes passed from the Python code to Windows
- but the reverse is true - only the data coming back from
FWIW, the most recent version of pywin32 has the following download
counts (rounded to the nearest thousand)
Version 32bit 64bit
-
3.2 - 75,000 9,000
3.1 - 4,000 1,000
2.7 - 126,000 16,000
2.6 - 46,000 6,000
2.5 - 21,000 n/a
2.4
On 17/02/2012 7:44 PM, Egon Smiwa wrote:
Hi all,
I'm an app developer with a CPython dll in the folder of that app.
In general, are there strict requirements about the dll name
(a preference would be python.dll (easy to update (simple replace) ).
I successfully used python.dll and a few standard
I'm wondering what thoughts are on PEP 397, the Python launcher for
Windows. I've been using the implementation for a number of months now
and I find it incredibly useful.
To my mind, the specific steps would be:
* Have someone pronounce it as accepted (or suggest steps to be taken
before
On 18/02/2012 4:37 PM, Brian Curtin wrote:
On Fri, Feb 17, 2012 at 23:24, Mark Hammondskippy.hamm...@gmail.com wrote:
I'm wondering what thoughts are on PEP 397, the Python launcher for Windows.
I've been using the implementation for a number of months now and I find it
incredibly useful.
On 18/02/2012 11:08 PM, mar...@v.loewis.de wrote:
Zitat von Mark Hammond skippy.hamm...@gmail.com:
I'm wondering what thoughts are on PEP 397, the Python launcher for
Windows. I've been using the implementation for a number of months now
and I find it incredibly useful.
I wonder what
On 21/02/2012 2:54 AM, Mark Lawrence wrote:
On 18/02/2012 05:24, Mark Hammond wrote:
...
* Write some user-oriented docs.
The section in the docs Using Python on Windows would need to be
updated, but would this have to happen for every current version of Python?
I'm not sure what docs you
On 22/02/2012 2:50 AM, Vinay Sajip wrote:
Mark Hammondskippy.hammondat gmail.com writes:
think there is something that could be added to those docs - the use of
PATHEXT and the fact that once the shebang line is in place, a
command-prompt could do just hello.py rather than needing py
On 14/03/2012 6:43 AM, VanL wrote:
Following up on conversations at PyCon, I want to bring up one of my
personal hobby horses for change in 3.3: Fix install layout on Windows,
with a side order of making the PATH work better.
Short version:
1) The layout for the python root directory for all
[resending - original reply went only to Van]
On 15/03/2012 10:15 AM, Lindberg, Van wrote:
On 3/14/2012 5:39 PM, Mark Hammond wrote:
Can you offer any examples of 3rd party tools which could unify code
in this scheme, and particularly, where this scheme would cause them
to have less code
On 16/03/2012 8:57 AM, VanL wrote:
On 3/14/2012 6:30 PM, Mark Hammond wrote:
So why not just standardize on that new layout for virtualenvs?
That sounds like the worst of all worlds - keep all the existing special
cases, and add one.
I'm not so sure. My concern is that this *will* break
1 - 100 of 230 matches
Mail list logo
