ion is using a python.dll located outside the Python
directory). I'm sure there are pros and cons for including that directory,
but I can't see justification for it to sometimes be used and sometimes not.
So should I change msi.py to include this directory, or change pyconfig.h to
not in
to
> support him at some point as well).
And until then, a +1 for MAL's position from me as well. 2.x should be
quite conservative about such changes...
Cheers,
Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org
e, it seems Guido is against changing this behaviour
even for 3k.
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
reader-friendly text version.
>
> The needed sources could then be distributed with Python -- it shouldn't
> be more than about 200 kb.
>
+1 from me. Would this mean that htmllib and sgmllib could be
removed without further ado.
Mark
___
Pytho
uot; isn't the correct
abstraction here, but maybe a "factory" approach, so the entire process
creation mechanism can be replaced rather than just the name of the
executable to spawn?
Cheers,
Mark
___
Python-Dev mailing list
Python-Dev@pytho
27;re stored. So maybe this should stay. (Though I've
occasionally wondered why three-argument pow is part of the
core language, rather than being in the standard library.)
Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/m
little to do with implementation
details and use or not of __bin__, and (b) I should have
said this in the issue tracker a few days ago.
Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubsc
C99, Java, ...)
I have to admit that I can't see much use for octal floats.
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
x literals uses a similar format; the standard is less
specific about the precise output format, but it's still of the form
0x1.p
Incidentally, the funny 'p' for the exponent instead of 'e' is apparently
there to avoid ambiguity in something like:
0x1e+3
Mark
___
ng floating point numbers as hex, there should
> also be support for hex floating point literals.
>
I agree with this. Or at least support for hex floating point
strings, if not literals.
>
> Also, to follow C's tradition, it would be better if that was
>
On Thu, Jun 26, 2008 at 9:55 PM, Mark Dickinson <[EMAIL PROTECTED]> wrote:
>
> It's disadvantage from Python's point of view is that some features are IEEE
> 754
Aargh! I can't believe I wrote that. Its. Its. Its. Anyway; some
more detail:
Both C99 and Jav
On Thu, Jun 26, 2008 at 10:28 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Remind me what %a does?
From the C99 standard (section 7.19.6.1):
A double argument representing a floating-point number is converted in the
style [−]0xh.p±d, [...]
___
P
e magnitude of the number, and
- the exponent doesn't vary with changes to the least significant bits
of the float.
The disadvantage is the loss of evalability. (Is that a word?)
Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail
On Thu, Jun 26, 2008 at 11:00 PM, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Let me remind you that %a currently means "call ascii()" in 3.0.
Oh well. That's out then. I'll rephrase to "I'd be delighted with something
similar
On Thu, Jun 26, 2008 at 11:00 PM, Terry Reedy <[EMAIL PROTECTED]> wrote:
> Definitely. The paper I referenced in the issue discussion,
> http://bugs.python.org/issue3008 mentioned a few times here, is
> http://hal.archives-ouvertes.fr/docs/00/28/14/29/PDF/floating-point-article.pdf
Perhaps it'
und to the nearest float, but since part of the
point of hex floats is having a way to specify a given value
*exactly*, it might make more sense to raise an exception
rather than changing the value by rounding it.
Mark
___
Python-Dev mailing li
intf (a, A)."""
More recent 754r drafts spell the grammar out explicitly instead of
referring to C99,
and weaken the 'shall' (i.e., 'is required to') to a 'should' ('is
recommended to').
Mark
___
Pyt
//bugs.python.org/file10780/hex_float.py
It might be useful for testing.
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
t; we don't tend to use ".toxyz()" as a naming convention much in Python.
Would it be totally outrageous for the float constructor to accept
hex strings directly?
Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.
MAL mentioned and all others with
their own native unicode implementations would agree.
Cheers,
Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/optio
easons to prefer math module functions over float methods, or
vice versa?
Personally, I'm leaning slightly towards float methods: for me, these
conversions are important enough to belong in the core language. But I
don't have strong feelings either way.
Mark
__
everywhere, even on major platforms. (Examples are the inverse hyperbolic
trig functions in math.h.)
And the specific question:
(2) Is it okay to use the '%a' format specifier for sprintf, sscanf and friends.
Are there major platforms where this isn't implemented? (Using
'%a&#x
dea in principle, but I still need to:
- get permission from Barry to check in a new feature
this late in the release cycle, and
- persuade some other developer to review the patch.
I'll gladly 'pay' for a patch review by reviewing one or
more o
er the assumption that everyone is
out to give you cause to "resent" things...
As Steve said, this is getting silly...
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
cent thread on python-dev
http://mail.python.org/pipermail/python-dev/2008-June/080558.html
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
;f' formatting that there is no exponent?
In C, the only difference seems to be that a NaN or infinity formatted with '%F'
is turned into "NAN" or "INF" instead of "nan" or "inf".
Mark
___
Python
On Wed, Jul 16, 2008 at 4:14 PM, Daniel Stutzbach
<[EMAIL PROTECTED]> wrote:
> There's no exponent for small-magnitude numbers, but still an exponent
> for large-magnitude numbers:
>
>>>> '%f' % (10**100)
> '1e+10
, part of my brain still
believes that something formatted with 'F' should have all letters appearing
in upper case.
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
tly
> transparent and innocuous to all existing uses _feels_ right, because
> it's more practical.
For the record, and primarily to give the champion of this proposal a little
more resolve the run the python-dev gauntlet on this issue given the recent
-
into
making sure that repr() or str() of an infinity or nan is 'inf' or 'nan'
(or '-inf'), regardless of platform.
+1 for normalizing '%f' and '%F' behaviour across platforms.
Mark
___
Python-Dev mai
environment will solve the vast majority of the errors - except for the
bsddb and wsgi ones, which don't look particularly Windows specific...
Hope that helps a bit...
Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/ma
4.2 for debug builds.) Is this an
appropriate fix?
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
> Can anybody verify and hopefully fix the problems seen in the Windows
> bots for the trunk (i.e. 2.6)?
FWIW, I can't reproduce most of those problems. My 32bit build sees:
303 tests OK.
57 tests skipped:
test__locale test_aepack test_al test_applesingle test_bsddb185
test_bsddb3 test_c
Antoine writes:
> Mark Hammond skippinet.com.au> writes:
> >
> > However, test_cpickle takes a different path and doesn't see this
> doubling of
> > the count - therefore dieing at the depth of 629 that I can see.
>
> 629 is a very low number, far low
> I believe it's the wrong diagnosis :)
As I mentioned in the bug, I believe you are correct :)
Thanks!
Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.py
; executable), but it
> fails on Linux because it *only* executes the first argument in the
> list ("svn") and does not pass the remaining arguments in the list to
> the "svn" invocation.
It sounds like in this particular example at least, this behaviour on Linux
is the problem?
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
is very
important!)
FWIW, my opinion is similar to how I read Martin's - that if a suitable,
safe patch that cleanly uninstalls can be found, it should be included, but
disabled by default. Personally I'd never use it.
Cheers,
Mark
___
P
> Mark Hammond skippinet.com.au> writes:
> > >
> > > The reason for adding the directory to the PATH is for it to be
> > > recognized in any command prompt, not only the Python-dedicated
> > > command prompt shortcut.
> >
> > Actually,
Barry writes:
> In addition, Mark reported in IRC that there are some regressions in
> the logging module.
3772 logging module fails with non-ascii data
Which according to the IRC discussion doesn't apply to py3k. The fix for
2.6 is quite trivial...
Ch
es are more a list of references and problems
CapPython needs to address than an explanation of the current design.
There was also a thread about CapPython on the e-lang mailing list:
http://www.eros-os.org/pipermail/e-lang/2008-August/012828.html
Mark
[1] http://code.google.co
Terry Reedy <[EMAIL PROTECTED]> wrote:
> Mark Seaborn wrote:
> > Private attributes may only be accessed through "self" variables.
> > "Self" variables are defined as being the first arguments of functions
> > defined inside class definitions,
"Guido van Rossum" <[EMAIL PROTECTED]> wrote:
> On Thu, Sep 18, 2008 at 2:15 PM, Mark Seaborn <[EMAIL PROTECTED]> wrote:
> > Yes. The renaming of "im_self" and "im_func" is good. The removal of
> > unbound methods is a *big* pro
distutils script in py2x syntax, but execute it via py3k. Its very possible
this already exists and I've just missed it...
Either way, I'm fairly confident a pywin32 build for py3k will be available
in the next month or 2 (but as a result, I'm not really in a position to
help w
hich, although py3x
compatible, are being maintained in py2x syntax. Below is my quick attempt
at such a script, which I promptly stopped looking at as soon as it worked
(ie, I'm not sure if all those options are needed, etc), but it does let me
execute my tests using py3k directly from th
> at such a script, which I promptly stopped looking at as soon as it
> worked
Which is quite obvious really given that:
> # nuke ourselves from argv
> del sys.argv[1]
is removing the wrong value!
Mark
___
Python-Dev mailing lis
from a manifest (FWIW, the CRT will abort() if
initialized other than via a manifest!).
I don't see a downside and can see how it would help with private
assemblies.
[I've also added a comment to this effect to the bug]
Mark.
___
Python-
> Mark Hammond schrieb:
> >> In http://bugs.python.org/issue4120, the author suggests that it
> might
> >> be possible to completely stop using the manifest mechanism, for VS
> >> 2008. Given the many problems that this SxS stuff has caused, this
> >> soun
to turn this into the appropriate 32x32-bit hardware multiply.
I agree that very-long-integer optimizations probably don't really belong in
Python, but this patch should also provide significant benefits for short
and medium-sized integers. I guess I need to go away and do some
benchmarking...
M
ifdef in longintrepr.h for defining digit, twodigits, stwodigits
etc, and a couple more for the places where digits are read and written
in marshal.c.
>> I agree that very-long-integer optimizations probably don't really belong in
>> Python,
>
> Depends in part on whether
bits) and eax (low 32 bits);
this explains why edx has to be zeroed with the 'xorl' instruction.
And if we were really expecting a 64-bit result then there should
be an unsigned multiply (mull) there instead of a signed multiply
(imull); of course they're the same
dx
which looks a lot like a 64 x 64 -> 64 multiply to me. This
seems inefficient, when a 32 x 32 -> 64 bit multiply ought
to be good enough. But maybe there isn't a significant
performance difference on x86_64?
Mark
___
Python-Dev mailing li
e minor bugs in longobject.c that I think should be applied
to 2.6.1 and 3.0.1 (not worth it for 3.0). I'll try to put together a
separate patch containing these. They're mostly either missing casts
or places where int should have been changed to Py_ssize_t.
discussion: e.g. z.real, z.imag
Thoughts?
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 Wed, Nov 12, 2008 at 12:16 AM, Mark Dickinson <[EMAIL PROTECTED]> wrote:
> precisely, the ceiling of the log to base 2 of the integer). See
D'oh. s/ceiling/1+floor/
Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://m
mething other than a power-of-2 base.
Right: numbits is only a natural property of a *binary* integer.
On the other hand, I can't realistically see Python ever adopting a
non power-of-two based implementation.
Mark
___
Python-Dev mailing
;-> int
conversion. And it turns out that overall performance doesn't suffer:
I've coded up a Python extension module that implements decimal
integers (stored internally in base 10**9) whose performance handily
beats that of the current binary int/long.
Mark
___
ves would be made easier if the Python MSI installer
was split up to support "merge modules"? That way you could roll your own
installer that met any guidelines or requirements that mattered to you,
while still ensuring you got all the files that the official installer
icular, is created by MSVC 6.0, which isn't
> even capable of dealing with manifests.
>
> Would it help compliance if we renamed them into .dat, so that the
> conformance test doesn't recognize them as .exe files?
That is probably a good idea regardless of the
Just plonk what you need (or
*everything* except what you know you don't need, eg docs) in the same
directory structure, test, rinse and repeat. Ideally you would also tweak
the resource in pythonxx.dll which tells it the registry key to use too. If
you had special UAC requirements
required
> expect for the uninstalled key which is already clean.
So to be clear, you don't desire any changes here?
BTW - isn't there also a "\Program Files" requirement...?
Cheers,
Mark
___
Python-Dev mailing list
Python-Dev@
ust acknowledge it is still only a theoretical concern.
However, should such a situation arise, my position would probably be that
unless it was MS suggesting it be preloaded on *all* PCs, we should
sacrifice that part of being "OEM Ready" to best look after the interests of
people who
also be a consequence of the
weaker IEEE 754-1985 requirements, but I'm not sure.
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
cimal string is carried to the
maximum precision specified in Table 2, namely, 9 digits for single and 17
digits for double.
"""
Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubs
Greg writes:
> Mark Hammond wrote:
>
> > The only conflict I see here is the requirement to install into
> "\Program Files"
>
> Doesn't that just mean that if an OEM decides to preinstall it,
> they need to put it in Program Files? They're at liberty t
1) IEEE 754 compliance is intended, and (2) there are people at
Symbian who care about fixing non-compliance issues. It makes the
currently fairly insane activity of trying to write cross-platform
floating-point C code that's going to work on any system that
Python
On Fri, Nov 28, 2008 at 4:48 PM, Torne Wuff
<[EMAIL PROTECTED]> wrote:
> Are you aware of any compliance suite, test vectors, etc we could
> 'borrow' to verify our implementation?
See also the ucbtest package, available from http://www.netlib.org/fp/
___
with unspecified changes has?
Of course, I don't object to that and still think we should help where we
can, but if that is true it would make the premise of this thread a little
misleading, as obviously HP could then make *any* necessary changes without
our agreement or even knowledge.
stions:
(1) If I commit a change to the trunk that I don't want to go into
release26-maint, should I explicitly block it using svnmerge?
(2) Same question for trunk -> py3k
(3) Same question for py3k -> release30-maint.
I'm guessing that the answers are
2-67524,67539,67541,67559,67588' to
'/python/trunk:1-61437,...,67467,67484,67528'.
(where the ... abbreviates a big long list of revision numbers).
Did I mess up somewhere, or does svnmerge not work on
a revision that was itself the result of an svnmerge?
Mark
___
ugs.python.org
That way it's less likely to get lost. :)
Thanks,
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
ssa would have in that
case, but surely not more than 117.
I asked a related question a while ago:
http://mail.python.org/pipermail/python-dev/2008-February/076680.html
Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.or
provides, or about what the C compiler
and library support? Or something else entirely?
It looks like IEEE-conforming 128-bit floats would have a 113-bit
mantissa (including the implicit leading '1' bit).
Mark
___
Python-Dev mailing list
Pyth
On Tue, Dec 9, 2008 at 5:24 PM, Mark Dickinson <[EMAIL PROTECTED]> wrote:
> I don't know of any. There are certainly places in the codebase that
> assume 56 bits are enough. (I seem to recall it's something like
> 56 bits for IBM, 53 bits for IEEE 754, 48 for Cray, and
oating point.
Decimal is *already* floating-point. Its handling of exponents
and significant zeros mean that it can do a pretty good job of
imitating fixed-point as well, but it's still at root a floating-point
type.
Mark
___
Python-Dev mailing l
thon
executable, so that it's available to a dynamically loaded extension
module?
I've found the -u option to gcc, but this doesn't seem like a
particularly portable solution. Of course, if this problem exists
only on OS X, then the solution doesn't need to be portable.
Thanks,
latforms whose
math libraries haven't caught up with C99. The rest is only
(possibly) needed in the math and cmath modules. In fact,
on OS X none of pymath.c is needed at all, which results in
lots of "ranlib: file: libpython2.7.a(pymath.o) has no symbols"
in
Hi,
Just wondered if/when there'd be a Mac installer for Python 3?
Thanks!
--
Mark Summerfield, Qtrac Ltd, www.qtrac.eu
C++, Python, Qt, PyQt - training and consultancy
"Programming in Python 3" - ISBN 0137129297
___
Pyt
already know that, so I doubt I understand the question...
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
xceptions then occur happen as normal without terminating the
process? Given it is an edge-case, I thought I'd open it here for
discussion before putting work into a patch or opening a bug.
Thanks,
Mark
___
Python-Dev mailing list
Python-Dev@python.org
code CRT is available of course -
if not, I guess you'd need to call the win32 api instead of _wopen.
Alternatively, the PyArg_ParseTuple() call could possibly be changed to
use the 'e' format string
Hoping-that-was-what-you-were-asking, ly,
Mark
__
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
ects
Repository UUID: 6015fed2-1504-0410-9fe1-9d1591cc4771
Revision: 68358
Node Kind: directory
Schedule: normal
Last Changed Author: marc-andre.lemburg
Last Changed Rev: 68344
Last Changed Date: 2009-01-05 13:43:35 -0600 (Mon, 05 Jan 2009)
Thanks.
mips-ffi.patch
Description: Binary data
-
n* (as
opposed to Decimal method) that takes a Decimal, int or long
and returns a Decimal; similarly for exp, log, log10, ...
Another thing that has been requested recently on c.l.p.
is good implementations of trig functions for Decimal, which
are quite hard to do properly.
Mark
I noticed that the builtin numeric types (int, float, complex) all still
have a __long__ method in 3.x. Shouldn't this have disappeared as
part of the int/long unification? Is there any reason not to remove this
(by setting the nb_long entry to 0 in all three cases)?
it to nb_reserved.
I see uses of nb_long in Object/abstract.c and Modules/_struct.c, but
no others in the core. I think the first can be removed, and the
second changed
to nb_int.
Patch at
http://bugs.python.org/issue4910
Thanks,
Mark
___
Python-Dev
norwitz-x86/build/Lib/unittest.py", line
> 345, in failUnlessRaises
>callableObj(*args, **kwargs)
> IOError: [Errno 9] Bad file descriptor
At the risk of stating the obvious, shouldn't you be checking for
IOError rather than OSError in assertRaises?
Mark
___
certainly looks like it: here are lines 6632--6638 of
posixmodule.c, in posix_ftruncate:
Py_BEGIN_ALLOW_THREADS
res = ftruncate(fd, length);
Py_END_ALLOW_THREADS
if (res < 0) {
PyErr_SetFromErrno(PyExc_IOError);
return NULL;
uire (at least) a tracker discussion.
In the meantime, please could you either revert or fix the r68547 checkin?
It looks as though *all* of the (non-Windows) trunk buildbots are failing on
test_os, and if any of the release managers notices we'll all be in
On Thu, Jan 15, 2009 at 10:40 PM, Kristján Valur Jónsson
wrote:
> Right. I've fixed the remainder, things should quiet down now.
> K
Thank you!
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubsc
Now that all uses of nb_long and __long__ have disappeared from
the 3.x codebase, would it make sense to mark PyNumber_Long
as deprecated in the c-api documentation, and convert all existing
uses (I count a grand total of 3 uses in the py3k branch!) to
PyNumber_Int?
(The two functions behave
good to deprecate one or the
other; I don't really have a strong opinion about which one.
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
I don't see this sort of thing happening, but it seems
like an attractive strategy, since it allows one to test one
particular buildbot (via the form for requesting a build)
without messing up anything else.
What do others do to debug these failures?
Mark
(P.S. After a bit of Googling, I sus
problems (though I think it's
more likely that they're Haiku floating-point
problems). I'd be interested to see short
code-snippets that reproduce these issues.
- I wouldn't worry so much about the test_math
and test_cmath failures until you get the others
sorted
> have the developers get access to the buildbot slaves.
Thanks, Martin. I think I've pretty much run out of time to
pursue this particular problem for the moment; I may return
to it later. It's good to know that these options are available,
though.
Mark
__
ith MSVC built binaries, I can't work out
why you are fricking around with msvcr80 either!
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
/bugs.python.org/issue1717) for 3.0.1?
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
ed (which used
to be nb_long) in the PyNumberMethods structure.
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
opinion it is safe to change the type of tp_reserved
from (cmpfunc *) to some other (dummy) function pointer?
I now realize (thanks to your message) that changing the type
to (void *) isn't entirely safe, since sizeof(void*) may be
different from sizeof(cmpfunc*
On Sun, Feb 1, 2009 at 4:21 PM, Guido van Rossum wrote:
> Sounds like Martin is referring to your suggestion to raise an
> exception when initializing a type that has a non-NULL thing here. I
> agree with him.
Got it. Thank you.
Mark
___
P
ut it. The best reference I could find (besides
the C standards themselves, and in particular section 6.3.2.3 of
the C99 standard) was an ancient and short discussion on
comp.std.c (starting June 21, 1998, subject
"Q: void pointers and function pointers") where some
1001 - 1100 of 1370 matches
Mail list logo
