Re: [Python-Dev] Rounding float to int directly (Re: struct module and coercing floats to integers)
Greg Ewing wrote: > Raymond Hettinger wrote: > >> I think this would harm more than it would help. It more confusing to >> have several rounding-thingies to choose from than it is have an >> explicit two-step. > > But is it more confusing enough to be worth forcing > everyone to pay two function calls instead of one > in the most common case? I suppose you don't know about the optional argument to round that lets you round up to a certain decimal ?! If we were to follow your suggestion, we'd have round() return an integer when called without the argument and a float when called with the argument. Dependency of the return type on arguments to a function should be avoided, if possible. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Aug 01 2006) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ 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
Re: [Python-Dev] Which version of distutils to ship with Python 2.5?
Martin v. Löwis wrote: > Anthony Baxter schrieb: >>> In any case, I bumped the version number to 2.5, according to the >>> policy discussed in >>> >> Could this not simply use the Python version number directly, instead? > > See the prior discussion at > > http://mail.python.org/pipermail/distutils-sig/2005-January/004366.html > > Some people still believe (at least, believed in January 2005), that > distutils is developed independently of Python, and thus deserves > its own version number. They still do. Even if distutils is part of the stdlib, it is a software package that's intended to be used for more than just the latest Python release. The fact that were no official separate distutils releases shouldn't be regarded as meaning that there's no interest in using distutils with older Python versions. > Of course, Andrew Kuchling officially declared in r1982 of pep 291 > that there won't be any further stand-alone distutils releases, > and therefore, backwards compatibility with 2.1 is not necessary > anymore. AFAIK, there was no public discussion about this on the distutils SIG list. While I don't think that Python 2.1 compatibility is still a requirement, Python 2.3 compatibility should be maintained in order to make SVN distutils work with all versions of Python since 2.3. distutils should then be added back to PEP 291. > So I changed distutils.__version__ again, to be derived from > sys.version_info. See the discussion on the checkins list for why this will only cause problems instead of fixing any. http://mail.python.org/pipermail/python-checkins/2006-July/055139.html > I left the numerous comments still in distutils that compatibility > with 2.1 is desired. We should remove these after 2.5 is released > (or perhaps even before that). Please don't. Instead we should have a discussion about this whole issue on the distutils list and then decide. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Aug 01 2006) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ 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
Re: [Python-Dev] Bad interaction of __index__ and sequence repeat
Travis Oliphant wrote: >> Probably the most interesting thing now would be for Travis to review >> it, and see whether it makes things easier to handle for the Numeric >> scalar types (given the amount of code the patch deleted from the >> builtin and standard library data types, hopefully the benefits to >> Numeric will be comparable). > > > I noticed most of the checks for PyInt where removed in the patch. If I > remember correctly, I left these in for "optimization." Other than > that, I think the patch is great. You're right - there was a fast path based on PyInt_Check in _PyEval_SliceIndex that got lost, which I'll add back in. I'll also add fast paths for PyInt_Check to the functions in abstract.c, too. The other PyInt_Check's (in slot_nb_index and instance_index) were there to check that __index__ returned the right thing. The check was still there in slot_nb_index, but I'd incorrectly removed it from instance_index. I'll add that one back in, too. Once that's done, I'll update the tracker item and reassign to Tim for a review. Cheers, Nick. > As far as helping with NumPy, I think it will help to be able to remove > special-checks for all the different integer-types. But, this has not > yet been done in the NumPy code. > > -Travis > > > -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ 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
Re: [Python-Dev] Rounding float to int directly (Re: struct module and coercing floats to integers)
M.-A. Lemburg wrote: > I suppose you don't know about the optional argument > to round that lets you round up to a certain decimal ?! Yes, I know about, but I rarely if ever use it. Rounding a binary float to a number of decimal places seems a fundamentally ill-considered thing to do anyway. What are the use cases for it, given that one can easily select a number of decimal places when formatting a number for display? > If we were to follow your suggestion, we'd have round() > return an integer when called without the argument and > a float when called with the argument. No, round() wouldn't have that option at all. If you wanted it, you would use fround() instead, which would have the option and return a float always. This would be a Py3k thing, obviously. If done before then, the new function would have to be given a different name. -- Greg ___ 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
Re: [Python-Dev] Rounding float to int directly (Re: struct module and coercing floats to integers)
Greg Ewing wrote: > M.-A. Lemburg wrote: > >> I suppose you don't know about the optional argument >> to round that lets you round up to a certain decimal ?! > > Yes, I know about, but I rarely if ever use it. > Rounding a binary float to a number of decimal > places seems a fundamentally ill-considered thing > to do anyway. What are the use cases for it, > given that one can easily select a number of decimal > places when formatting a number for display? You often have a need for controlled rounding when doing financial calculations or in situations where you want to compare two floats with a given accuracy, e.g. to work around rounding problems ;-) The usual approach is to use full float accuracy throughout the calculation and then apply rounding a certain key places. Float formatting is an entirely different issue. >> If we were to follow your suggestion, we'd have round() >> return an integer when called without the argument and >> a float when called with the argument. > > No, round() wouldn't have that option at all. If > you wanted it, you would use fround() instead, > which would have the option and return a float > always. > > This would be a Py3k thing, obviously. If done > before then, the new function would have to be > given a different name. Hmm, looks like a YAGNI to me, but perhaps I'm missing something :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Aug 01 2006) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ 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
Re: [Python-Dev] Rounding float to int directly ...
"M.-A. Lemburg" <[EMAIL PROTECTED]> wrote: > > You often have a need for controlled rounding when doing > financial calculations or in situations where you want to > compare two floats with a given accuracy, e.g. to work > around rounding problems ;-) The latter is a crude hack, and was traditionally used to save cycles when floating-point division was very slow. There are better ways, and have been for decades. > Float formatting is an entirely different issue. Not really. You need controlled rounding to a fixed precision in the other base. But I agree that controlled rounding in binary does not help with controlled rounding in decimal. Regards, Nick Maclaren, University of Cambridge Computing Service, New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email: [EMAIL PROTECTED] Tel.: +44 1223 334761Fax: +44 1223 334679 ___ 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
Re: [Python-Dev] Rounding float to int directly (Re: struct module and coercing floats to integers)
On Tue, Aug 01, 2006, M.-A. Lemburg wrote: > > You often have a need for controlled rounding when doing financial > calculations or in situations where you want to compare two floats > with a given accuracy, e.g. to work around rounding problems ;-) > > The usual approach is to use full float accuracy throughout the > calculation and then apply rounding a certain key places. That's what Decimal() is for. (Note that I don't care all that much about round(), but I do think we want to canonicalize Decimal() for all purposes in standard Python where people care about accuracy. Additional float features can go into NumPy.) -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." --Brian W. Kernighan ___ 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
Re: [Python-Dev] Rounding float to int directly ...
Aahz <[EMAIL PROTECTED]> wrote: > On Tue, Aug 01, 2006, M.-A. Lemburg wrote: > > > > You often have a need for controlled rounding when doing financial > > calculations or in situations where you want to compare two floats > > with a given accuracy, e.g. to work around rounding problems ;-) > > > > The usual approach is to use full float accuracy throughout the > > calculation and then apply rounding a certain key places. > > That's what Decimal() is for. Well, maybe. There are other approaches, too, and Decimal has its problems with that. In particular, when people need precisely defined decimal rounding, they ALWAYS need fixed-point and not floating-point. > (Note that I don't care all that much about round(), but I do think we > want to canonicalize Decimal() for all purposes in standard Python where > people care about accuracy. Additional float features can go into > NumPy.) Really? That sounds like dogma, not science. Decimal doesn't even help people who care about accuracy. At most (and with the reservation mentioned above), it means that you can can map external decimal formats to internal ones without loss of precision. Not a big deal, as there ARE no requirements for doing that for floating-point, and there are plenty of other solutions for fixed-point. People who care about the accuracy of calculations prefer binary, as it is a more accurate model. That isn't a big deal, either. Regards, Nick Maclaren, University of Cambridge Computing Service, New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email: [EMAIL PROTECTED] Tel.: +44 1223 334761Fax: +44 1223 334679 ___ 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
Re: [Python-Dev] Rounding float to int directly ...
Nick Maclaren wrote: Well, maybe. There are other approaches, too, and Decimal has its problems with that. In particular, when people need precisely defined decimal rounding, they ALWAYS need fixed-point and not floating-point. The decimal spec was designed to encompass both floating-point and fixed-point. (Note that I don't care all that much about round(), but I do think we want to canonicalize Decimal() for all purposes in standard Python where people care about accuracy. Additional float features can go into NumPy.) Really? That sounds like dogma, not science. Decimal doesn't even help people who care about accuracy. At most (and with the reservation mentioned above), it means that you can can map external decimal formats to internal ones without loss of precision. Not a big deal, as there ARE no requirements for doing that for floating-point, and there are plenty of other solutions for fixed-point. People who care about the accuracy of calculations prefer binary, as it is a more accurate model. That isn't a big deal, either. Hogwash. The only issues with decimal are ease-of-use and speed. Raymond ___ 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
Re: [Python-Dev] Rounding float to int directly ...
Raymond Hettinger <[EMAIL PROTECTED]> wrote: > > Hogwash. The only issues with decimal are ease-of-use and speed. I suggest that you get hold of a good 1960s or 1970s book on computer arithmetic, and read up about "wobbling precision". While it is not a big deal, it was regarded as such, and is important enough to cause significant numerical problems to the unwary - which means 99.99% of modern programmers :-( And, as I am sure that Aahz could point out, there are significant reliability issues concerned with frequent base changes where any loss of precision is unacceptable. Yes, it can always be done, but only a few people are likely to do it correctly in all cases. Regards, Nick Maclaren, University of Cambridge Computing Service, New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email: [EMAIL PROTECTED] Tel.: +44 1223 334761Fax: +44 1223 334679 ___ 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
Re: [Python-Dev] Bad interaction of __index__ and sequence repeat
Nick Coghlan wrote: > Travis Oliphant wrote: >>> Probably the most interesting thing now would be for Travis to review >>> it, and see whether it makes things easier to handle for the Numeric >>> scalar types (given the amount of code the patch deleted from the >>> builtin and standard library data types, hopefully the benefits to >>> Numeric will be comparable). >> >> I noticed most of the checks for PyInt where removed in the patch. If I >> remember correctly, I left these in for "optimization." Other than >> that, I think the patch is great. > > You're right - there was a fast path based on PyInt_Check in > _PyEval_SliceIndex that got lost, which I'll add back in. I'll also add fast > paths for PyInt_Check to the functions in abstract.c, too. > > The other PyInt_Check's (in slot_nb_index and instance_index) were there to > check that __index__ returned the right thing. The check was still there in > slot_nb_index, but I'd incorrectly removed it from instance_index. I'll add > that one back in, too. > > Once that's done, I'll update the tracker item and reassign to Tim for a > review. Aside from the 'assign to Tim' part, this is done now (pep357-fix-v3 on the tracker item). I also tweaked the clipping version of the C API to optionally expose the overflow flag that abstract.c was using internally so the client code can find out whether or not clipping actually occurred. The patch also updates the index unit tests to: - cover the various type errors that Travis picked up - actually run the full set of unit tests under -O - only run the basic sequence independent tests once (instead of once per sequence type) Neal also had a number of questions that I responded to in the tracker comments. The most significant question related to the API signature, which Neal considered potentially confusing: PyNumber_Index(PyObject *item, int *is_index) I added the is_index flag to the function signatures instead of providing a separate PyNumber_IndexCheck function in order to avoid doing the same type check twice in the typical mp_subscript implementation cases. One possibility would be to invert the sense of that flag and call it "typeerror", which probably more accurately reflects what it's intended for - it's a way of telling the function "if this object does not have the correct type, tell me by setting this flag instead of by setting the Python error state". Regards, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ 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
[Python-Dev] clock_gettime() vs. gettimeofday()?
This has probably been discussed before, however ... Is there any reason to use clock_gettime() in preference to gettimeofday() if it exists? It pretends to at least return seconds + nanoseconds, where gettimeofday() returns seconds + microseconds. Are there perhaps some platforms where it's possible to actually get more useful bits? On my Solaris 10/Intel desktop box clock_getres shows 0.01s resolution (not obviously better) while on a Linux box here it shows 0.001s resolution. Is that better than what gettimeofday() does? Skip ___ 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
Re: [Python-Dev] Rounding float to int directly ...
Nick Maclaren wrote: > "M.-A. Lemburg" <[EMAIL PROTECTED]> wrote: >> You often have a need for controlled rounding when doing >> financial calculations or in situations where you want to >> compare two floats with a given accuracy, e.g. to work >> around rounding problems ;-) > > The latter is a crude hack, and was traditionally used to save cycles > when floating-point division was very slow. There are better ways, > and have been for decades. > >> Float formatting is an entirely different issue. > > Not really. You need controlled rounding to a fixed precision in > the other base. But I agree that controlled rounding in binary > does not help with controlled rounding in decimal. I'm -1 on implicitly converting to an int when rounding. One reason is if your rounded (to int type) number is then used in an equation you my end up with a integer result when you wanted a floating point result. >>> 23.5/5.2 4.5192307692307692 >>> round(23.5)/round(5.2) 4.7998 >>> round(23.5/5.2) 5.0 >>> int(round(23.5))/int(round(5.2)) 4 Which one of these is correct probably depends on what you are using the result for. If it's an intermediate calculation you may not want an integer (type) result just yet. Rounding is used in various differing ways in regard to significant digits and accuracy. While it seems like there should be one easy way of handling rounding and significant digits, that would be too narrow a view. See the following page (for starters) to see various uses and rules of significant digits and rounding and how they change depending on the type of calculation and weather or not its a pure or exact number: http://www.epcc.edu/faculty/victors/sigfig.htm I think it's better to view that the common operation (being discussed) is rounding when converting to an int, and not converting to an int when rounding. So the standard idiom mentioned earlier by Raymond ... int(x+.5) If it could be made faster by having a round argument on int for such operations, it may be worth while. int(x, round=mode) Where mode could be one of 'up','down','standard','toeven','toodd', or whatever are useful methods that might be used. If there is no performance advantage to combining the two, I think it would be better to keep them separate. So I'm -0 on giving the int constructor a rounding argument. Just my 2 cents, Ron ___ 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
[Python-Dev] Strange memo behavior from cPickle
We seem to have stumbled upon some strange behavior in cPickle's memo
use when pickling instances.
Here's the repro:
[mymodule.py]
class C:
def __getstate__(self): return ('s1', 's2', 's3')
[interactive interpreter]
Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import cPickle
>>> import mymodule
>>> class C:
... def __getstate__(self): return ('s1', 's2', 's3')
...
>>> for x in mymodule.C(), C(): cPickle.dumps(x)
...
"(imymodule\nC\np1\n(S's1'\nS's2'\np2\nS's3'\np3\ntp4\nb."
"(i__main__\nC\np1\n(S's1'\nS's2'\nS's3'\ntp2\nb."
>>>
Note that the second and third strings in the instance's state are
memoized in the first case, but not in the second. Any idea why this
occurs (and why the first element is never memoized)?
--Bruce
___
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
Re: [Python-Dev] Strange memo behavior from cPickle
[Bruce Christensen]
> We seem to have stumbled upon some strange behavior in cPickle's memo
> use when pickling instances.
>
> Here's the repro:
>
> [mymodule.py]
> class C:
> def __getstate__(self): return ('s1', 's2', 's3')
>
> [interactive interpreter]
> Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit (Intel)] on
> win32
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import cPickle
> >>> import mymodule
> >>> class C:
> ... def __getstate__(self): return ('s1', 's2', 's3')
> ...
> >>> for x in mymodule.C(), C(): cPickle.dumps(x)
> ...
> "(imymodule\nC\np1\n(S's1'\nS's2'\np2\nS's3'\np3\ntp4\nb."
> "(i__main__\nC\np1\n(S's1'\nS's2'\nS's3'\ntp2\nb."
> >>>
>
> Note that the second and third strings in the instance's state are
> memoized in the first case, but not in the second. Any idea why this
> occurs (and why the first element is never memoized)?
Ideally, a pickle would never contain a `PUT i` unless i was
referenced by a `GET i` later. So, ideally, there would be no PUT
opcodes in either of these pickles.
cPickle is a little bit smarter than pickle.py here, in that cPickle
suppresses a PUT if the reference count on the object is less than 2
(in which case the structure being pickled can't possibly reference
the sub-object a second time, so it's impossible that a later GET will
want to reference the same sub-object). So all you're seeing here is
refcount accidents, complicated by accidents concerning exactly which
strings get interned.
Use pickle.py instead (which doesn't do this refcount
micro-optimization), and you'll see the same number of PUTs in both.
They're all correct. What would be incorrect is seeing a `GET i`
without a preceding `PUT i` using the same `i`.
___
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
Re: [Python-Dev] Rounding float to int directly (Re: struct module and coercing floats to integers)
M.-A. Lemburg wrote: > You often have a need for controlled rounding when doing > financial calculations You should NOT be using binary floats for money in the first place. > or in situations where you want to > compare two floats with a given accuracy, Pseudo-rounding to decimal places is not the right way to do that. The right way is to compare the difference to a tolerance. > e.g. to work > around rounding problems ;-) As Tim Peters has pointed out many times, you can't fix binary/decimal representation problems by rounding. There are always cases that give a different result than you would want. > Hmm, looks like a YAGNI to me, In all my programming so far I've found numerous uses for round-to-int, and exactly zero uses for round-binary-float-to-decimal- places. So from my point of view, the YAGNI applies to the *current* behavour of round()! -- Greg ___ 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
Re: [Python-Dev] Rounding float to int directly (Re: struct module and coercing floats to integers)
On Sat, 29 Jul 2006 15:44:33 +1200 Greg Ewing <[EMAIL PROTECTED]> wrote: > Michael Urman wrote: > > The fact that > > round returns a float rather than an int, while intentional, does not > > feature prominently in one's mine when the first version yielded the > > expected results. > > As an aside, does anyone else think that it would be > useful to have a builtin which rounds and converts to > an int in one go? Whenever I use round(), I almost > always want the result as an int, and making me do > it in two steps seems unnecessarily bothersome. It's not even clear to me that int(round(x)) is always the nearest integer to x. Is it always true that float(some_int)>=some_int ? (for positive values). (ie. I am wondering if truncating the float representation of an int always gives back the original int). Simon. -- Simon Burton, B.Sc. Licensed PO Box 8066 ANU Canberra 2601 Australia Ph. 61 2 6249 6940 http://arrowtheory.com ___ 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
[Python-Dev] internal weakref API should be Py_ssize_t?
I'm wondering if the following change should be made to Include/weakrefobject.h: -PyAPI_FUNC(long) _PyWeakref_GetWeakrefCount(PyWeakReference *head); +PyAPI_FUNC(Py_ssize_t) _PyWeakref_GetWeakrefCount(PyWeakReference *head); And the 2 other files which use this (weakref obj and module). Should this be changed now, wait for 2.6, or not worry about it? n ___ 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
Re: [Python-Dev] internal weakref API should be Py_ssize_t?
[Neal Norwitz] > I'm wondering if the following change should be made to > Include/weakrefobject.h: Yes. > -PyAPI_FUNC(long) _PyWeakref_GetWeakrefCount(PyWeakReference *head); > +PyAPI_FUNC(Py_ssize_t) _PyWeakref_GetWeakrefCount(PyWeakReference *head); > > And the 2 other files which use this (weakref obj and module). Should > this be changed now, wait for 2.6, or not worry about it? +1 on biting the bullet for 2.5. ___ 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
Re: [Python-Dev] internal weakref API should be Py_ssize_t?
Neal Norwitz wrote: > I'm wondering if the following change should be made to > Include/weakrefobject.h: On Wednesday 02 August 2006 00:53, Tim Peters wrote: > Yes. ... > +1 on biting the bullet for 2.5. Agreed. This should definately go with the rest of the Py_ssize_t changes. -Fred -- Fred L. Drake, Jr. ___ 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
[Python-Dev] Weekly Python Patch/Bug Summary
Patch / Bug Summary ___ Patches : 396 open ( -5) / 3354 closed (+12) / 3750 total ( +7) Bugs: 864 open (-32) / 6087 closed (+52) / 6951 total (+20) RFE : 226 open ( +2) / 234 closed ( +1) / 460 total ( +3) New / Reopened Patches __ Move firewall warning to "about" menu (2006-07-26) http://python.org/sf/1529018 opened by Tal Einat Allowing multiple instances of IDLE with sub-processes (2006-07-26) http://python.org/sf/1529142 opened by Tal Einat Squeezer - squeeze large output in the interpreter (2006-07-27) http://python.org/sf/1529353 opened by Tal Einat More openbsd targets for ctypes (2006-07-27) CLOSED http://python.org/sf/1529514 opened by Thomas Heller test_defaultdict not integrated into test sute (2006-07-27) CLOSED http://python.org/sf/1529686 opened by iga Seilnacht misleading info about tarfile.py's "r|*" mode (2006-07-27) CLOSED http://python.org/sf/1529811 opened by Lars Gustäbel pydoc render_doc (2006-07-28) http://python.org/sf/1530482 opened by ganges master test_email_codecs not integrated into test sute (2006-07-27) CLOSED http://python.org/sf/1529686 reopened by zseil Fix __index__() clipping really big numbers (2006-07-29) http://python.org/sf/1530738 opened by Nick Coghlan "a + (2006-07-29) CLOSED http://python.org/sf/1531113 opened by Christopher Tur Lesniewski-Laas Tracing and profiling functions can cause hangs in threads (2006-07-31) http://python.org/sf/1531859 opened by Matt Fleming Support for case-insensitivity in string.Template (2006-07-25) CLOSED http://python.org/sf/1528167 reopened by whit537 Patches Closed __ Expose case-insensitivity of string.Template (2006-07-25) http://python.org/sf/1528167 closed by bwarsaw Fix for #1513611 and #1511497; xml.sax imports (2006-07-10) http://python.org/sf/1519796 closed by zseil More openbsd targets for ctypes (2006-07-27) http://python.org/sf/1529514 closed by theller test_defaultdict not integrated into test sute (2006-07-27) http://python.org/sf/1529686 closed by gbrandl misleading info about tarfile.py's "r|*" mode (2006-07-27) http://python.org/sf/1529811 closed by akuchling Support for PyGetSetDefs in pydoc, inspect, and types (2006-07-10) http://python.org/sf/1520294 closed by bwarsaw Fix socketmodule compile on NetBSD (2006-07-21) http://python.org/sf/1526460 closed by splitscreen test_email_codecs not integrated into test sute (2006-07-27) http://python.org/sf/1529686 closed by gbrandl Describe Py_DEBUG and friends... (2006-05-18) http://python.org/sf/1490989 closed by akuchling os.path.exists returns False if no permission (2004-11-17) http://python.org/sf/1068277 closed by akuchling "a + (2006-07-29) http://python.org/sf/1531113 closed by nnorwitz Fix zip file header format in zipfile.py (2003-07-30) http://python.org/sf/780595 closed by gbrandl Don't produce core file in test_subprocess.py (2006-07-11) http://python.org/sf/1520905 closed by akuchling New / Reopened Bugs ___ readline module description should mention raw_input() (2006-07-26) CLOSED http://python.org/sf/1529157 opened by Thom Harp possible bug in mystrtol.c with recent gcc (2006-07-13) CLOSED http://python.org/sf/1521947 reopened by nnorwitz unrelated variable messing up doctests (2006-07-26) CLOSED http://python.org/sf/1529297 reopened by macquigg BROWSER path with capital letters (2006-07-28) http://python.org/sf/1529655 opened by Ken McGaugh doc string of read-only properties (2006-07-27) CLOSED http://python.org/sf/1529717 opened by Michael Amrhein distutils regression related to Distribution.run_command (2006-07-27) CLOSED http://python.org/sf/1529871 opened by Collin Winter bz2 lib missing from source distribution (2006-07-27) CLOSED http://python.org/sf/1529998 opened by james yoo Mac Universal Build of Python confuses distutils (2006-07-28) http://python.org/sf/1530142 opened by Richard Jones ssl object documentation lacks a couple of methods (2006-07-28) CLOSED http://python.org/sf/1530382 opened by Lawrence Oluyede file.seek() influelce write() when opened with a+ mode (2006-07-12) http://python.org/sf/1521491 reopened by rudnik_lior ctypes build fails on Solaris 10 (2006-07-28) http://python.org/sf/1530448 opened by Skip Montanaro struct.pack raises TypeError where it used to convert (2006-07-28) http://python.org/sf/1530559 opened by Joe Wreschnig distutils doesn't notice --with-pydebug (2006-07-29) http://python.org/sf/1530959 opened by Collin Winter __weaklist__ in typeobject.c (2006-07-29) http://python.org/sf/1531003 opened by Fred L. Drake, Jr. Comman not allowed at the end of argument list for **argumen (2006-07-29)
