e outlined the
topics that we discussed below.
Present:
Antonio Cuni
Mark Dickinson
Larry Hastings (chair)
Marc-André Lemburg
Ezio Melotti
Antoine Pitrou
Armin Ronacher
Armin Rigo
Mark Ramm
Topics covered
==
Python 3 adoption
-
urgency on
actually doing this... I'll make an effort to update that reference
impl in the next week or so (but obviously anyone else is free to help ;)
Cheers,
Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/ma
n BitBucket if anyone's interested,
but it's a work in progress. I'm working on some simple tests.
Sure, that would be awesome! I think that will mean your impl is fairly
close to the first draft of the PEP I checked into HG, which is nice and
still quite useful to use :)
Thank
On 1/07/2011 7:20 PM, Vinay Sajip wrote:
Mark Hammond gmail.com> writes:
The intention is that there only be a single launcher, as only one app
can be associated with .py files. OTOH though, file associations can be
configured per-user IIRC, and assuming that is the case, we could avoid
On 2/07/2011 7:08 PM, Vinay Sajip wrote:
Mark Hammond gmail.com> writes:
The PEP does say "if possible, should be installed somewhere likely to
already be on the system PATH (eg., the Windows System32) directory."
It is silent about what to do when that isn't possible, but
On 4/07/2011 3:59 PM, Greg Ewing wrote:
Mark Hammond wrote:
On 2/07/2011 7:08 PM, Vinay Sajip wrote:
perhaps we could remember the last non-launcher association when we
install the launcher,
It might be better to look in the registry for other Python
installations and ask the user which
pects of launching Python.
If the launcher is such that we can unconditionally recommend its use,
IMO we should just install it with Python. I'll go with the consensus
though...
Mark
___
Python-Dev mailing list
Python-Dev@python.org
http
ct to the above? Or to put it another way, does anyone believe
dropping the Python reference implementation is to the detriment of the PEP?
Thanks,
Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/pytho
idea is to go anywhere, it would need adding to
the PEP. Mark, do you think it would be useful?
I doubt I will find it useful - but I'm on record as saying I wont find
the custom command support itself useful :) But similarly with that
support, evidence that enough people *will* find it use
to be generated
to stdout.
Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
ters and even python-based apps. The launcher does not.
What other interpreters? IMO it doesn't make sense to have IronPython,
jython etc be installed there. Ditto for apps - especially given most
apps tend to be tied to a subset of all possible Python versions.
Mark
yet). It has slightly better debug output (although generally
not what you are asking for yet) and better "cross-bittedness" support.
Cheers,
Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
On 21/07/2011 10:08 AM, Antoine Pitrou wrote:
On Thu, 21 Jul 2011 09:55:28 +1000
Mark Hammond wrote:
> The two proposals
overlap but are not mutually exclusive. For future pythons, 'python33'
is easier to remember and type than 'py -v 3.3' or whatever the propose
Are you maybe forgetting about the PATHEXT functionality? If you
include .py in your PATHEXT and file associations are set so .py files
are handled by the launcher, you should be able to directly execute just
'foo' and have the command processor search the PATH for a foo.py and
d entail. If you want
this feature you should advocate for it to be added to Python itself and
it will then automatically work in the launcher too.
Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-
r if this directory is not writable.
I think this PEP is getting close to being finalized - please suggest
whatever changes you feel are necessary ASAP as soon I'll be asking for
pronouncement.
Thanks - especially to Vinay for taking on the C implementation!
Mark
PEP: 397
Title: Python launc
On 21/07/2011 6:32 PM, Glenn Linderman wrote:
On 7/20/2011 11:35 PM, Mark Hammond wrote:
* If the command starts with the definition of a customized command
followed by a space character, the customized command will be used.
See below for a description of customized commands
be a little more constructive and offer concrete
improvements?
Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%4
local configuration file _OR_ the is a
local configuration file without the setting.
I'll await a new launcher.
I just pushed a fix and hopefully Vinay will push a new MSI soon.
Thanks,
Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.
ressing with if it became the "blessed" build process for windows - if
there is support for this, I'll work on it as the opportunity presents
itself...
I'm (obviously) only suggesting we do this on the trunk and am happy to make
all agreed changes - but I welcome all suggestions
s
> > build process to a cygwin environment based on the existing autoconf
> > scripts?
>
> What compiler would you use there? I very much like using the VS
> debugger when developing on Windows, so that capability should not
> go away.
You would use whatever compiler the autocon
der
> > 'platform=Windows API', and WCHAR is very much an API concept. I'll
> > need to
> > dig some more into this, but at least I know I'm not
> > wasting my time :)
>
> Mark, your problem may be related to a setting in the "c/c++
&g
s.
And dragging distutils back op topic, having bdist_wininst supply a manifest
that indicates escalation is required appears necessary.
> Vista adoption is going very fast. We see 10% of our users have moved
> to vista and rising.
ack - I'm yet to try a 32 bit version, but
r.h; useable
>means wchar_t must be 16-bit unsigned type. (see
>Include/unicodeobject.h). */
> #if Py_UNICODE_SIZE == 2
> #define HAVE_USABLE_WCHAR_T
> #endif
>
> disabling the default settings in the unicodeobject.h.
Yes, that does appear strange. The
ld need to take
> > care that their environment pointed at the correct compiler
> - especially the
> > person building releases.
> >
> > But assuming MSVC was found and had the appropriate
> switches passed, there
> > would be no impact on the ability to use Visual
from the PCBuild8 directory. I hope it is clear that I am willing to
contribute the outcome of these discussions...
Cheers,
Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
htt
Perhaps this is an
> acceptable compromise?
Sure - that will work for me. I'll check this out and contact you by
private mail for further guidance.
Cheers,
Mark
<>___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.or
used for?
Please see PC/getpathp.c in Python source tree.
However, I agree that there are a number of things we could do to help
Python play nicely on Vista. It might help if we can enumerate the specific
problems and potential solutions in a more formal way (eg, a Python bug)
Cheers,
Mark
<>
et
confusing.)
Trent: I assume you use the same source tree for multiple platforms and
compilers, meaning that changing these "optional" build processes to copy
from PCBuild8/VC6 into PCBuild would cause pain? If not, do you think that
would be a reasonable solution?
Cheers,
Mark
nstalling it.
> If not how do you recommend getting myself to a state where I have at
least a feature complete
> distribution build against VS8? I'm happy with a one time build that I
can just install into
> my source tree and upload to the SCM.
I'd suggest that once I ch
s. A patch that allows the test suite to work in such
an environment would be welcome, but I think you might end up needing access
to GetShortPathName() rather than CreateProcess().
Cheers,
Mark
___
Python-Dev mailing list
Python-Dev@py
than the high-bit of GetVersion(), IMO it
should be replaced with GetVersionEx().
Cheers,
Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
velopers or when running the python test suite from the directory it
is built in, but your proposed fix is a patch to os.popen(). There would
also need to be new test cases added to demonstrate this bug in a "normal"
test run.
Cheers,
Mark
___
Py
-coded to 0 - but I've no idea if it is relevant.
Presumably it is relevant to *something*, otherwise it would not have been
created - but its unclear when and how this should be set to 1, and if this
should concern people trying to use bdist_msi to create x64 extension
packages - but for now, let
uld expect a correct x64 install to create)? I think you are agreeing,
but sounding a caution that it might not be trivial to fix, but I would like
to be sure...
Cheers,
Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/ma
MSI files are
> built, I can look into patching it. I don't have a convenient 64-bit
> Windows machine around to test any changes, though.
I think Tools\msi is what you are looking for, but hopefully Martin will
chime in. I'm more than happy to help test.
Cheers,
Mark
process see the
> > real keys - I'm not aware of how 64bit apps would enable
> > that reflection,
> > but it probably doesn't really matter for our purposes.
>
> They can specify KEY_WOW64_32KEY.
Ah - thanks.
Cheers,
Mark
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 reflecte
bdist_msi that
works only with the corrected version and I'm wondering the best way to get
people to test it...
Cheers,
Mark.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail
ur mail isn't clear enough for me to be sure about what semantics
you are seeing and exactly what you expect, and I don't have time to
experiment. Maybe a clear indication of the OS bug you are referring to,
and some complete examples which demonstrate the problems you are having
would he
e I was wrong. When I used
> `python 1.py>1.txt' it suddenly started working as expected. :-/ Must
> be some strange difference with how HKCR entries are parsed and then
> executed...
I think it is more about how the shell (ie, cmd.exe by default) (mis-)handles
the command-lin
['ssl/socketmodule.h']" fails for me - no header of that
name exists in the ssl directory in your archive.
After those changes I was able to get it built and tested:
"""
Ran 15 tests in 3.157s
OK
"""
Hope this helps,
Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
It might be possible to try and use build_ssl.py to locate the openssl
directory, but this will still require that someone building it has Python
built from source - I'm fairly sure that someone installing a Python binary
will not have build_ssl.py, nor ar
way it builds with the
openssl Python itself builds with.
Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
On 9/17/07, Facundo Batista <[EMAIL PROTECTED]> wrote:
>
> In the Tracker Issue...
>
> http://bugs.python.org/issue1772851
>
> ... Mark Dickinson came with a patch that alters in a very corner case
> how the hash is calculated to a long integer.
>
Much as I'
;d be quite surprised to find that *anyone* was
using the three-argument pow, but perhaps we should be careful here?
Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://
version giving
essentially the same functionality. I think the current decimal would
certainly benefit from a speedup: it's probably `fast enough' for many
applications, but it suffers horribly at high precisions: addition of
two n-digit decimals
multiplying fast (some fft-like multiplication) is
> worth it - depends on how many people would like to perform computations
> with prec around 100k+ digits ;).
I quite agree: people who want high-speed high-precision arithmetic
should probably be using some binary floating-point pac
c on top of it, whether written in
> C or pure Python (if some utility C functions such as for counting the
> number of digits an integer were available), would be both
> light-weight and efficient at high precision.
Agreed. But it might be hard to sell a more efficient decimal m
On 10/16/07, Daniel Stutzbach <[EMAIL PROTECTED]> wrote:
> On 10/16/07, Mark Dickinson <[EMAIL PROTECTED]> wrote:
> > the reverse conversion to get a Decimal result; both of these
> > conversions (tuple of digits <-> integer) take time quadratic in the
> >
m to get special treatment. I agree it is
unfortunate that the behaviour has changed, but these special names are
broken enough on Windows that (1) seems the sanest thing to do.
Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.
imal("2.5"))
> > 3.0
>
> Yes.
>
That seems a little peculiar to me: wouldn't it be more natural to have
round(Decimal_instance) return another Decimal?
Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.p
And
for each operation, it might also be useful to specify whether the result
should be padded with zeros to the desired length or not. (i.e. when
rounding 3.399 to 3 significant places, should it produce 3.4 or 3.40?)
Any thoughts?
Mark
___
x27;ve got so much out of Python over the years, and I hope I
can now give something back.
Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
s outside the scope
of the PEP and a question for the windows installer assuming the PEP be
accepted. Maybe some general hand-waving along the lines of "env vars on
Windows are left to the installer, where such global issues are considered
in a wider context" would do :)
Cheers,
Mark
___
a new release (it didn't manage a
single one in 2007!) and that is likely to happen before I get to play with
the new-fangled stuff
Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
tional(2476979795053773L,2251799813685248L).
So I'd say leave both these methods out for now---it would be easy enough to
add them later if it turns out there's a real need.
Just my 200/391 UK pennies :)
Mark
___
Python-Dev mailing list
Python-
On Jan 21, 2008 3:44 AM, Paul Moore <[EMAIL PROTECTED]> wrote:
> On 21/01/2008, Tim Peters <[EMAIL PROTECTED]> wrote:> By "useful" I
> don't mean lots of people will use it ;-) I mean /some/
> > people will use it -- a way to generate the sequence of convergents is
> > a fundamental tool that can
orm in each tree, and tools are
free to have ways of specifying which directory should be used. The
official build process need not change. However, it also supports a way to
do cross-compilation in a way that build tools can *automatically* locate
the correct platform's libraries, and this will
e means general agreement on the compromise proposal I
outlined?
Thanks,
Mark
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On
> Behalf Of Mark Hammond
> Sent: Tuesday, 22 January 2008 9:06 PM
> To: '"Martin v. Löwis"'
>
of the spectrum are embedded devices and cellphones. Here
I have no idea what the situation is at all---any information would be
valuable.
Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Uns
er people also run Python on z/OS.
>
Okay. So FLT_RADIX==2 can't be assumed, in general.
Thanks for the information.
Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://m
On Feb 1, 2008 8:04 PM, Christian Heimes <[EMAIL PROTECTED]> wrote:
> I spoke to Mikko Ohtamaa (Moo-- on #pys60) and he gave me the name of a
> Nokia developer and this link
> http://discussion.forum.nokia.com/forum/showthread.php?t=97263. I
> already contacted the developer and asked him to reply
stdata/normalize.decTest
(or possible Normalize.decTest). This file shouldn't be present in the
distribution (it's outdated).
Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
isnan(x)"
+1 on making these methods of float; they're fundamental properties.
Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
ues.
I fear that the per-thread state change seems like something where a PEP
might be necessary; it's also not clear right now that Christian and I have
exactly the same goals here (discussion is ongoing). But I hope that the
rest of the changes are uncontroversial enough to merit consideratio
/mail.python.org/pipermail/python-list/2008-February/477064.html
entitled "Turn off ZeroDivisionError?" for a recent discussion of these
issues.
I fear that the per-thread state change seems like something where a PEP
might be necessary; it's also not clear right now
ty feedback.
In the meantime, we'll get the rest of the fixes/additions tidied up in
trunk-math,
and hope for their inclusion in 2.6/3.0.
Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe
the fixes/additions tidied
up in trunk-math, and hope for their inclusion in 2.6/3.0.
Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/pytho
ckage will need to wait for 3.0to
> use the except/as form :-(
>
Not a problem. Decimal doesn't use "except Exception, err" anywhere
in those 5000 lines, as far as I can tell! :-)
Mark
___
Python-Dev mailing list
Python-Dev@python.org
al package will need to wait for 3.0 to
> use the except/as form :-(
It looks to me as though Decimal doesn't use "except Exception, err"
anywhere in those 5000 lines.
:-)
Mark
___
Python-Dev mailing list
Python-Dev@python.org
http
expect that turning the crank for a test
build needn't be that much or a burden. I expect the biggest problem is that I
could no longer ignore certain extensions I don't care about, such as Tk.
Cheers,
Mark
___
Python-Dev mailing list
P
head
around various MSI issues at any level (eg, bdist_msi needs some tweaking to
allow for different releases of the same "package" to be recognized as such,
but I'm not sure what MSI concept I'm dealing with yet...)
WiX is an excellent inspir
y that the chance
of getting 0.0 is about 1 in 2**53, so it's never going to happen...)
Other thoughts:
- what should x == x do?
- what should
1.0 in set([0.0, 1.0, 2.0])
and
3.0 in set([0.0, 1.0, 2.0])
do?
Mark
___
Python-Dev mailing list
Python-De
s test pass about 80%
of the time and fail the other 20% with something like the above,
the position of the reported invalid data changing from run to run. It
looks like data are getting corrupted somewhere along the line.
Anyone have any ideas?
Mark
_
It explains the randomness of the
failures, at least.
So it's probably not a C-level data corruption bug after all.
test_shlex seems to be one of the problem files. Investigations are continuing.
Trent, thanks for your help! I'll take further
misguided. Installing a package doesn't
require munging the registry and none of the popular installation techniques
do. Installing Python itself does, and some packages have special
requirements (eg, pywin32 registering COM objects), but in general, Python
packages on W
rced to str in Decimal.__new__.
If others agree that it's a bug, I'll fix it.
Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
rced to str in Decimal.__new__.
If others agree that it's a bug, I'll fix it.
Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
are masquerading as bytes instances, for reasons of
convenience/efficiency/something else?
Unicode/bytes/str and encoding issues frighten me much more than
floating-point arithmetic ever did, so I expect I'm missing many
things here.
Mark
___
Pytho
all last):
File "", line 1, in
File "/Users/dickinsm/python_source/py3k/Lib/fractions.py", line 98, in
__new__
numerator = numerator.__index__()
AttributeError: 'bytes' object has no attribute '__index__'
So int and float accepts bytes, while complex
On Tue, Mar 25, 2008 at 11:57 AM, Facundo Batista <[EMAIL PROTECTED]>
wrote:
> 2008/3/25, Mark Dickinson <[EMAIL PROTECTED]>:
>
> > So int and float accepts bytes, while complex, Decimal and Fraction do
> > not...
>
> I'm -1 to accept bytes as input for De
al to do really high precision arithmetic.
(Right now, addition of two Decimals takes quadratic time.)
The decimal long integer implementation is already in the sandbox,
so this probably isn't as much work as it sounds. I won't have time
for it until May, though.
Mark
___
d yet: there's another update to it expected some
time after IEEE 754r is finally approved, so there are probably
still significant changes to be made to Decimal in the future.
I know that I would have contributed a lot less to Decimal had
it been written in C, simply because it would have take
nstead.
>
Could you give me an example of the sort of adaptations that might be
necessary, or the API changes that would be necessary to make a
drop-in replacement possible?
Are you just talking about things like removing the context argument
from __add__ and friends, or i
equivalent should be.
>
Is there any easy way that the burden of trunk -> py3k
merging could be moved to the original committers of
the trunk patches? Presumably the original committer
of a patch is well-placed to understand what the patch
does and how
e if
there was some reason that this would be difficult or
undesirable.
I'm not suggesting that this be enforced (mechanically
or otherwise); just that it might be worth considering
instituting a policy to encourage individual committers
to take responsibility for forward porting their commits.
Ma
FYI, I've uploaded a patch that provides for cross-compilation on Windows
between 32 and 64 bit platforms - all comments invited!
Thanks,
Mark
-Original Message-
From: Mark Hammond [mailto:[EMAIL PROTECTED]
Sent: Sunday, 30 March 2008 6:01 PM
To: [EMAIL PROTECTED]
Subject: [issu
he VS project files should be reasonable.
What do people think? I think it's time to take the approach of "silent
ascent", so unless I hear objections I'll upload a new patch which
implements this and also takes it into account for Distutils builds.
Cheers,
Mark
___
tutils-sig/2007-May/007668.html; you are
replying to (I think) Kristján:
| > I am baffled about why the build environment's layout matters,
| > but once an .msi install can place the binaries in any
| > old place it wants. The build structure doesn't have to
| > reflect the
hon.exe"))
else:
# hrm - I obviously dont know about new platforms yet...
popen(exe, ...)
In other words, I think there is real advantage to simple scripts knowing
that './python' or './PCBuild/python.exe' will always be executable (and
always give the "na
tudio
2008, but that seems like a reasonable way to approach things. Are there
any objections to this, or should we stick with the status-quo and I'll add
the new x64 executable? Or do things that way *just* for x64?
Thanks,
Mark.
___
Python-De
r me in the short term. Should I just
check-in my cross-compilation patch as it stands then?
Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/opti
tory for posixmodule.c etc will offer some clues as to how this could
best be done.
Cheers,
Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
d maybe sharing the top-level script that generates the
profile data, etc)
Cheers,
Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
find anything
wrong with the libm implementation of log.
test_math is fine on Tru64/alpha.
Does anyone have access to a Linux/alpha machine, and a few minutes
to figure out exactly what's failing? Or any suggestions about what might
be failing. I'm open to wild ideas at this point... :-)
know this exist, so I'd be happy to create a patch which
add a new sys.iswow64process() process if desired.
Cheers,
Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://m
> -On [20080502 07:57], Mark Hammond ([EMAIL PROTECTED]) wrote:
> >The best way I can find for the win32 API to tell you this is a
> combination
> >of the above and the IsWow64Process() (which returns True if you are a
> >32bit process on a 64bit platform)
>
> S
g you to the nosy list, incase you wish to reject it
outright (but I'm likely to assume silence for a few weeks on a tracker
issue means no serious objections - at least none so serious they can't be
rectified by reverting the change)
Cheers,
Mark
:
|r63242 | alexandre.vassalotti | 2008-05-15 08:07:07 +1000 (Thu, 15 May
2008) | 2 lines
|
|Renamed the ConfigParser module to 'configparser'.
Is there something I've missed?
Cheers,
Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.py
901 - 1000 of 1370 matches
Mail list logo
