Re: [Python-Dev] why is mmap a builtin module on windows?
On Jan 26, 2008 12:06 AM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > > b) automate all aspects of adding modules that should not go > > into pythonxy.dll according to the policy." > > > > > > i.e. create visual studio project files for those modules? and make them > > built automatically? > > And adjust msi.py to package them automatically. > I have a working built environment now on windows (turns out it was rather easy). If time permits, I might have a look at it. - Ralf ___ 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] Organization of ABC modules
Guido van Rossum wrote: > I note that at least for built-in types there will be the naming > convention that concrete implementation classes are all lowercase, > like int, float, list, namedtuple, defaultdict, and so on, while the > ABCs all have a Capitalized[Words] name: Hashable, Number, Real, > MutableMapping, etc. That's a very good point. I also suspect that for any actual 2.6/3.0 code base I end up working with there will only be a very limited number of abstract base classes that get tested for via isinstance - so the red flag for isinstance checks would be types I didn't already recognise as being abstract base classes. Cheers, 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
Re: [Python-Dev] refleaks and caches
Neal Norwitz wrote: > I'm not sure we should expose an API to clear the cache, but I don't > have strong opinions either way. If we keep the ability to clear the > cache, should we also consider some control over the int/float > freelist? These are worse than the tuple/frame free lists since > int/floats are unbounded. I suspect the method free lists in > Objects/methodobject.c and Objects/classobject.c don't have that many > entries that could be removed. Do the int/float free lists cause any trouble or can they eat lots of memory? And what about the string intern list? > The biggest problem I have with the patch is the attribute name. I > would prefer underscores. ie _clear_type_cache instead of > _cleartypecache. Attributes in sys are currently inconsistent, but it > seems that most of the newer names have underscores. (Aside: if we > are going to move attrs out of sys for py3k, we should consider > renaming them to be consistent too. Regardless of moving them, should > we rename them.) The attribute name is the least problem. It's easy to fix. Brett came up with a nice idea, too. He suggested the gc module as the place for the function. Christian ___ 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] refleaks and caches
Brett Cannon wrote: > Ignoring whether this is the right thing to do, should this be in sys or in > gc? Yeah, good idea. The gc module makes sense. Christian ___ 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] Upcoming 2.4.5 and 2.3.7 releases
On Jan 27, 8:27 pm, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > Along with the release of 2.5.2, I would also like to release > new versions of 2.3 and 2.4. These will be security-only releases, > and include a few security-relevant bug fixes that are still being > finalized. > > As we don't have the infrastructure to produce full releases of 2.3 > or 2.4 anymore, this will be a source release only. As such, it > will likely see less testing than other releases, and users will have > more difficulties in obtaining the software for their system - the > releases will be targeted primarily at system vendors who can chose > to include them as security patches in their system updates. > > As a consequence, I would like to roll back all changes from the 2.3 > and 2.4 branches which aren't security fixes. In specific cases, the > nature of a change might be debatable; clear security fixes are > prevention of memory corruption and interpreter crashes, clear > non-security fixes are documentation and test-suite changes. > > For 2.3, there are only few revisions that would be rolled back: > r52798, r52803, r52824, r54342. > > For 2.4, the list is longer; all changes on the branch since > r52382 are candidate for roll-back. I would like to prepare > a white-list of patches that should be preserved; if you think > any of the patches committed in the 2.4 branch is a security > fix, please let me know. > > Regards, > Martin Don't know if this concerns 2.3 but there was a debate whether including patch #1745035 in 2.4 branch: http://groups.google.it/group/python-dev2/browse_thread/thread/33cad7b7c1cdb19f?hl=en# ___ 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] refleaks and caches
On Jan 27, 2008 3:37 PM, Christian Heimes <[EMAIL PROTECTED]> wrote: > Phillip J. Eby wrote: > > Expose an API to clear the cache, and clear it at shutdown? It > > should probably be part of interpreter shutdown anyway. > > Good point. I've implemented PyType_ClearCache and exposed it via > sys._cleartypecache(). The function is called during finalization, too. > Ignoring whether this is the right thing to do, should this be in sys or in gc? -Brett ___ 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] refleaks and caches
On Jan 27, 2008 3:37 PM, Christian Heimes <[EMAIL PROTECTED]> wrote: > Phillip J. Eby wrote: > > Expose an API to clear the cache, and clear it at shutdown? It > > should probably be part of interpreter shutdown anyway. > > Good point. I've implemented PyType_ClearCache and exposed it via > sys._cleartypecache(). The function is called during finalization, too. I'm not sure we should expose an API to clear the cache, but I don't have strong opinions either way. If we keep the ability to clear the cache, should we also consider some control over the int/float freelist? These are worse than the tuple/frame free lists since int/floats are unbounded. I suspect the method free lists in Objects/methodobject.c and Objects/classobject.c don't have that many entries that could be removed. There may not be a lot we can do for the int/float caches and I'm not sure if it's worth it. We can't move objects once created, although we could scan the blocks and if there are no live objects in a block, free it. That would presumably help with this case: list(range(some_big_number)) I don't know how important these things are in practice. > Can somebody please double check the change? The results are promising > and I'm sure I've implemented it correctly but you never know ;) The biggest problem I have with the patch is the attribute name. I would prefer underscores. ie _clear_type_cache instead of _cleartypecache. Attributes in sys are currently inconsistent, but it seems that most of the newer names have underscores. (Aside: if we are going to move attrs out of sys for py3k, we should consider renaming them to be consistent too. Regardless of moving them, should we rename them.) 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] trunc()
"Michael Urman" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] | 2) The semantics of int() are fuzzy; even non-numeric types | (strings) are handled One could just as well say that the semantics of float() are fuzzy since it also handles strings. The actual claim seems to have been that the semantics of int() itself is fuzzy. This in turn seems to be based one of two ideas (I am not sure which) a. 'int' might either mean to some people 'some int associated with the float input' rather than the more precise 'the integer part of the float input', or b. that some people might think the latter means the same as the former. Possibility a is easy taken care of by documentation, especially when the behavior is what people expect. Possibility b conflicts with what I believe to be both the plain English meaning of 'integer part' and what I believe Americans, at least, learn in elementary school. Moreover, I challenge the notion that 'truncate' is unambiguous. It simply means to cut off, without specifying how much. '3.141' is pi truncated to 3 decimal places. Indeed, it would not be unreasonable to expect trunc() to have a second parameter specifying where to cut. For one data point, I asked my bright 13-year-old for the 'integer part' of 3.1, 3.9, -3.1, and -3.9 and got the expected 3,3,-3,-3 (as with int()). But asking 'truncate' the same numbers or even 'truncate toward zero' got a blank stare, which did not surprise me too much as it is not a common (American) English word. tjr ___ 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] refleaks and caches
Phillip J. Eby wrote: > Expose an API to clear the cache, and clear it at shutdown? It > should probably be part of interpreter shutdown anyway. Good point. I've implemented PyType_ClearCache and exposed it via sys._cleartypecache(). The function is called during finalization, too. Can somebody please double check the change? The results are promising and I'm sure I've implemented it correctly but you never know ;) Christian ___ 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] functions vs methods (was Re: trunc())
On Jan 27, 2008 12:53 PM, Aahz <[EMAIL PROTECTED]> wrote: > This is why len() is not a method: > > map(len, list_of_strings) I disagree with that explanation -- I couldn't know that when I made len() a function, because map() wasn't to become part of the language for another 5-6 years. My explanation is (a) I translated ABC's #x notation, and (b) I like the way it looks better. Your explanation is at best a handy side effect. :-) -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] trunc()
On Jan 27, 2008 11:54 AM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > > If I'm following this discussion properly, the advantage of trunc() is > > that a Real-class-that-isn't-float can define a __trunc__ that can > > return an Integer-class-that-isn't-int, right? > > Depends on what you compare to. Compared to int(), the advantage is > that trunc() sends a clear message what its semantics is. > > > In that case, why not have the Real ABC grow trunc(), ceil(), floor(), > > and round() methods (replacing the __ varieties), and get rid of the > > builtins/math-module functions? > > > > x.trunc() is just as clear as trunc(x), and doesn't require a builtin. > > +1. Students just asked me why len() is not a method, and I didn't know > a good answer; the same holds for many other builtins. This is a clear > candidate for a method, IMO. Well, there's the generic functions line of thought, which isn't quite dead yet. And there's the idea that the built-in function can check that the result has a certain type, like len(), which insists on returning an int. But mostly it's because I find things like len(x), round(x) and cos(x) read more natural than method notation. It builds on a long tradition in math and applied math in programming language -- at least round() and cos() do, and so does trunc(). IOW it's a matter of aesthetics, and will never be explainable to everyone's satisfaction. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] trunc()
On Jan 27, 2008 12:12 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > [GvR] > >> > - trunc(), round(), floor() and ceil() should all be built-ins, > >> > corresponding to __trunc__, __round__, __floor__ and __ceil__. > > In Py2.6, what will the signatures be? > Last I heard, ceil() and floor() were still going to be float-->float. When imported from math, yes, for 2.5 compatibility. If we add builtins, the builtins won't have this restriction. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] functions vs methods (was Re: trunc())
On Jan 27, 2008 12:53 PM, Aahz <[EMAIL PROTECTED]> wrote: > On Sun, Jan 27, 2008, "Martin v. L?wis" wrote: > > > > Students just asked me why len() is not a method, and I didn't know a > > good answer; the same holds for many other builtins. This is a clear > > candidate for a method, IMO. > > This is why len() is not a method: > > map(len, list_of_strings) > > What I don't know is to what extent this argument still holds in the > presence of listcomps and genexps: > > [s.len() for s in list_of_strings] > > However, you still need ``len`` as a function to pass around as a > callback in other cases where you need a generic function because the > type of your data is not predetermined. > Or you just use ``lambda x: x.len()`` for the callback. And a built-in could easily be created that does what the lambda is doing. I know for me the reason I always thought the built-ins were there on top of using a method naming convention for operator overloading was so that a reasonable default could be provided by the built-in (e.g., iter() being able to work with an object that only provides __getitem__(), on top of its second argument allowing for better iteration control). > In any event, I consider dropping len() from builtins to be gratuitous > breakage, even in 3.0. I don't think anyone is proposing that. -Brett ___ 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] functions vs methods (was Re: trunc())
On Sun, Jan 27, 2008, "Martin v. L?wis" wrote: > > Students just asked me why len() is not a method, and I didn't know a > good answer; the same holds for many other builtins. This is a clear > candidate for a method, IMO. This is why len() is not a method: map(len, list_of_strings) What I don't know is to what extent this argument still holds in the presence of listcomps and genexps: [s.len() for s in list_of_strings] However, you still need ``len`` as a function to pass around as a callback in other cases where you need a generic function because the type of your data is not predetermined. In any event, I consider dropping len() from builtins to be gratuitous breakage, even in 3.0. -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ "All problems in computer science can be solved by another level of indirection." --Butler Lampson ___ 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] trunc()
[GvR] >> > - trunc(), round(), floor() and ceil() should all be built-ins, >> > corresponding to __trunc__, __round__, __floor__ and __ceil__. In Py2.6, what will the signatures be? Last I heard, ceil() and floor() were still going to be float-->float. 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] refleaks and caches
At 05:05 PM 1/26/2008 -0800, Neal Norwitz wrote: >Around Jan 13, the refleak hunting test that is reported on >python-checkins started to report refleaks on virtually every run. I >suspect this is due to r59944 (at 2008-01-13 16:29:41) which was from >patch #1700288 to cache methods. With this patch it makes it much >harder to spot refleaks. Does anyone have ideas how to fix it? The >only one I have is to disable the cache with a special flag, env't >variable, sys variable/function or the like. We could make this >available only in debug mode. The cache should normally be enabled, >but could be disabled solely on the refleak runs. > >Suggestions? Expose an API to clear the cache, and clear it at shutdown? It should probably be part of interpreter shutdown anyway. ___ 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] trunc()
> If I'm following this discussion properly, the advantage of trunc() is
> that a Real-class-that-isn't-float can define a __trunc__ that can
> return an Integer-class-that-isn't-int, right?
Depends on what you compare to. Compared to int(), the advantage is
that trunc() sends a clear message what its semantics is.
> In that case, why not have the Real ABC grow trunc(), ceil(), floor(),
> and round() methods (replacing the __ varieties), and get rid of the
> builtins/math-module functions?
>
> x.trunc() is just as clear as trunc(x), and doesn't require a builtin.
+1. Students just asked me why len() is not a method, and I didn't know
a good answer; the same holds for many other builtins. This is a clear
candidate for a method, IMO.
> The syntax when used on float literals is ugly ("2.56 .round()"), but
> there's no use case for these methods on literals (just write "3").
Actually, it works fine for float literals:
py> 2.45.round()
Traceback (most recent call last):
File "", line 1, in
AttributeError: 'float' object has no attribute 'round'
It's only int literals which have a problem with methods, but then,
you won't call any of these on an int literal, normally.
Regards,
Martin
___
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] Upcoming 2.4.5 and 2.3.7 releases
Along with the release of 2.5.2, I would also like to release new versions of 2.3 and 2.4. These will be security-only releases, and include a few security-relevant bug fixes that are still being finalized. As we don't have the infrastructure to produce full releases of 2.3 or 2.4 anymore, this will be a source release only. As such, it will likely see less testing than other releases, and users will have more difficulties in obtaining the software for their system - the releases will be targeted primarily at system vendors who can chose to include them as security patches in their system updates. As a consequence, I would like to roll back all changes from the 2.3 and 2.4 branches which aren't security fixes. In specific cases, the nature of a change might be debatable; clear security fixes are prevention of memory corruption and interpreter crashes, clear non-security fixes are documentation and test-suite changes. For 2.3, there are only few revisions that would be rolled back: r52798, r52803, r52824, r54342. For 2.4, the list is longer; all changes on the branch since r52382 are candidate for roll-back. I would like to prepare a white-list of patches that should be preserved; if you think any of the patches committed in the 2.4 branch is a security fix, please let me know. Regards, Martin ___ 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] trunc()
Guido van Rossum wrote: > On Jan 27, 2008 9:26 AM, Andrea Griffini <[EMAIL PROTECTED]> wrote: >> Anyway I want just to say that if "implicit" conversion from float >> to integer goes away then what happens to formatting conversion ? >> Removing that too IMO would break a lot of code and it's IMO very >> difficult to help fixing that. > > The formatting code could assign specific meanings. I suspect though > that it was never meant to be possible to use %d with a float -- it > just is one of the artifacts of using implicit conversion, and one not > well-thought through. Note: > "%.0f" % 3.99 > '4' "%d" % 3.99 > '3' > > I think the latter is wrong and confusing. format() has the same issue, for the same reason: >>> format(3.9, 'f') '3.90' >>> format(3.9, 'd') '3' I never noticed this before, and it's a definite error. PEP 3101 says the valid types for float are 'eEfFgGn%' and an empty string. I'll remove the integer conversion in the float formatter. Eric. ___ 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] trunc()
On Jan 27, 2008 10:43 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> - trunc(), round(), floor() and ceil() should all be built-ins,
> corresponding to __trunc__, __round__, __floor__ and __ceil__. Then we
> have the four standard ways to go from Reals to Integers, which are
> properly extensible for folks who write their own number types. (We
> can't control how folks implement __round__, but we can document
> expected behavior -- that's how we treat __add__ and all other
> operators too, after all.)
If I'm following this discussion properly, the advantage of trunc() is
that a Real-class-that-isn't-float can define a __trunc__ that can
return an Integer-class-that-isn't-int, right?
In that case, why not have the Real ABC grow trunc(), ceil(), floor(),
and round() methods (replacing the __ varieties), and get rid of the
builtins/math-module functions?
x.trunc() is just as clear as trunc(x), and doesn't require a builtin.
The syntax when used on float literals is ugly ("2.56 .round()"), but
there's no use case for these methods on literals (just write "3").
2to3 could handle this conversion pretty easily in most cases, so
there won't be much breakage.
--
Daniel Stutzbach, Ph.D. President, Stutzbach Enterprises LLC
___
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] trunc()
On Jan 27, 2008 10:54 AM, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > > Then int() can be defined by deferring to trunc() > > -- as opposed to round(). > > That part is new and represents some progress. If I understand it > correctly, it means that we won't have both __int__ and __trunc__ > magic methods. That's a good thing. A single type wouln't need both. But int() should still try both, because it doesn't make sense for e.g. a date type to have to define __trunc__ for conversion to an int. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] Upcoming 2.5.2 release
It is my pleasure to announce that I have been appointed as the release manager for the upcoming releases. For 2.5.2, I would like to release a candidate on February 14, and the final version on February 21. As Guido already mentioned, this will be a bug fix release only; no new features allowed. Kind regards, Martin ___ 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] trunc()
On Jan 27, 2008 10:39 AM, Michael Urman <[EMAIL PROTECTED]> wrote:
> Is this a valid summary of the arguments so far?
>
> I see two arguments for the change:
>
> 1) The semantics of trunc() are clear: it maps R -> Z in a specific fashion
> 2) The semantics of int() are fuzzy; even non-numeric types
> (strings) are handled
>
> Yet there will be a __trunc__ that will allow any chosen mapping to be
> implemented, so long as it results in an integer, so (1) is only
> guaranteed true for the builtin types.
We can easily add docs to the Real ABC indicating that __trunc__
*should* implement a certain semantics, just like we do (or should do)
for __add__ and everything else.
While this doesn't provide a hard guarantee in the presence of
non-conforming implementations, it's as good as it gets anywhere in
Python. Given that __int__ may be implemented for things that aren't
reals (like dates), it's much harder to prescribe what it *should* do.
> This leaves us with (2) which
> seems strongly tied to string parsing (as __index__ resolved the other
> common X -> integer case).
>
> I see one main argument against:
>
> *) trunc() results in duplication at best, zealous deprecation at worst
>
> Given that the deprecation or removal of int(2.3) has been dropped,
> the argument is about pointless duplication.
To some it's pointless. To others there's a fine point to it.
> What problem is trunc() supposed to solve if it does to floats what
> int() does now? I've done some initial code searches for: lang:python
> "int(", and I've seen three primary uses for calling int(x):
>
> a) parsing strings, such as from a user, a config file, or other
> serialized format
> b) limiting the input to a function to an integer, such as in a
> calendar trying to ensure it has integer months
> c) truncation, such as throwing away sub-seconds from time.time(),
> or ensuring integer results from division
>
> It's unclear to me whether (b) could be better served by more
> type-specific operations that would prevent passing in strings, or
> whether uses like (c) often have latent bugs due to truncation instead
> of rounding.
Case (b) should be using index() instead. Most likely the code either
predates index() or needs to be compatible with Python versions that
don't have it, or the programmer wasn't aware of index(), which hasn't
received a lot of publicity.
> If trunc() is to clarify round vs. integer-portion, it's something
> people learn -- the general lack of comments in (c) usages indicates
> nobody considers it special behavior. If it's to clarify the
> argument's type (the parsing of strings vs. getting integers from
> other numeric types), would separating parsing from the int (and
> float) constructors also solve this?
But there's a long-standing tradition that all numeric types in Python
accept a string as argument. This was just added to decimal too.
> Is the aim to "clean up" the following fake example? (Real world uses
> of map(int, ...) seem almost uniformly related to string parsing.)
>
> >>> map(int, ("42", 6.022, 2**32))
> [42, 6, 4294967296L]
That's an artificial example and hence it is impossible to derive the
intent of the programmer. Heterogeneous lists are pretty rare.
Let me give another artificial example.
Suppose I have a need to implement floats and ints that print
themselves in hex. I can make it so that this property is maintained
across addition etc. without having to change the code that *uses*
these numbers. But code that uses int() to convert a float to an int
will lose the property. If that code used trunc() instead I can
provide a __trunc__ on my hexfloat that returns a hexint. QED.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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] trunc()
> Then int() can be defined by deferring to trunc() > -- as opposed to round(). That part is new and represents some progress. If I understand it correctly, it means that we won't have both __int__ and __trunc__ magic methods. That's a good thing. 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] trunc()
On Jan 27, 2008 10:29 AM, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > > [Guido] > >> There is actually quite an important signal to the reader that is > >> present when you see trunc(x) but absent when you see int(x): with > >> trunc(x), the implication is that x is a (Real) number. With int(x), > >> you can make no such assumption -- x could be a string, or it could be > >> a totally different type that happens to define __int__, perhaps a > >> custom date/time type (I believe mxDateTime supports this). > > > > Can I assume that you agree with this? That would be progress. > > I agree that it provides a cue that that input is Real. > I don't agree that that has any value. We had a lot of tools that > can accept multiple input types. For instance, float() can accept > a string or number. We could do like C and split-out the atof() > functionality but that just makes two functions where one would suffice. All I claim is that it has *some* value for me. If it doesn't have value for you, that doesn't make it worthless. > > Yet another (minor) argument that has always made me uncomfortable > > with int() == trunc(): the % operator. I think it's a big improvement > > over C that Python's % operator is defined as > > > > x%y == x - y*floor(x/y) # where / is real division > > > > rather than C's division, which uses trunc() instead of floor(). In C > > this nicely meshes with the definition of int(): you can define x%y as > > x - y*(int)(x/y); but not so in Python. I don't want to use this as an > > argument for defining int(x) as floor(x), but I do want to point out > > that it has always given me a twinge of discomfort. > > It hasn't bugged me much, but I do understand. Progress. > > After all that, here's my current proposal: > > > > - Deprecating int() is pretty radical, I think it would have to > > happen in the distant future. OR not at all. I'm at best +0 on this, > > more like exactly 0. I realize that in practice this kills the idea. > > The "purist" argument for it would have worked better if it was made > > 18 years ago. > > "pretty radical" is what I meant when I said "it's nuts" ;-) > > This is a major piece of progress. Most of the prior proposal was > predicated on int() being deprecated. Good. > > - trunc(), round(), floor() and ceil() should all be built-ins, > > corresponding to __trunc__, __round__, __floor__ and __ceil__. Then we > > have the four standard ways to go from Reals to Integers, which are > > properly extensible for folks who write their own number types. (We > > can't control how folks implement __round__, but we can document > > expected behavior -- that's how we treat __add__ and all other > > operators too, after all.) > > ISTM, you really don't need trunc() in this mix. The ceil() and floor() > functions do an excellent job of convering most use cases. Not really. You'd have to use an if predicated on the sign to emulate trunc() using ceil() and floor(). Or something like sign(x) * floor(abs(x)) -- but we don't have sign(). > The overlap of trunc() and int() just isn't worth it. There's the mental > cost of having to explain the difference on day one to every beginner. > There's the back end cost of every class that has __int__ also needing > to decide whether to provide __trunc__ which will typically be the > same thing. > > In time, I believe it will become self-evident that having both int() > and trunc() is a wart. If trunc() goes into 2.6 and 3.0, then we're > going to have to live with this for a long time. > > Purity may suggest that you need trunc(). Practicality says it isn't > worth the cost. > > At least we've made important progress by saving int(). I don't see much cost for end users at all. It's not like trunc() represents a difficult concept. Having trunc() in addition to ceil(), floor() and round() creates a nicely complete set of float->int conversions. Then int() can be defined by deferring to trunc() -- as opposed to round(). My proposal stands (less any talk of deprecation of int()). -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] trunc()
Is this a valid summary of the arguments so far?
I see two arguments for the change:
1) The semantics of trunc() are clear: it maps R -> Z in a specific fashion
2) The semantics of int() are fuzzy; even non-numeric types
(strings) are handled
Yet there will be a __trunc__ that will allow any chosen mapping to be
implemented, so long as it results in an integer, so (1) is only
guaranteed true for the builtin types. This leaves us with (2) which
seems strongly tied to string parsing (as __index__ resolved the other
common X -> integer case).
I see one main argument against:
*) trunc() results in duplication at best, zealous deprecation at worst
Given that the deprecation or removal of int(2.3) has been dropped,
the argument is about pointless duplication.
What problem is trunc() supposed to solve if it does to floats what
int() does now? I've done some initial code searches for: lang:python
"int(", and I've seen three primary uses for calling int(x):
a) parsing strings, such as from a user, a config file, or other
serialized format
b) limiting the input to a function to an integer, such as in a
calendar trying to ensure it has integer months
c) truncation, such as throwing away sub-seconds from time.time(),
or ensuring integer results from division
It's unclear to me whether (b) could be better served by more
type-specific operations that would prevent passing in strings, or
whether uses like (c) often have latent bugs due to truncation instead
of rounding.
If trunc() is to clarify round vs. integer-portion, it's something
people learn -- the general lack of comments in (c) usages indicates
nobody considers it special behavior. If it's to clarify the
argument's type (the parsing of strings vs. getting integers from
other numeric types), would separating parsing from the int (and
float) constructors also solve this?
Is the aim to "clean up" the following fake example? (Real world uses
of map(int, ...) seem almost uniformly related to string parsing.)
>>> map(int, ("42", 6.022, 2**32))
[42, 6, 4294967296L]
--
Michael Urman
___
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] trunc()
On Jan 27, 2008 9:26 AM, Andrea Griffini <[EMAIL PROTECTED]> wrote: > On Jan 27, 2008 5:43 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > > - Deprecating int() is pretty radical, I think it would have to > > happen in the distant future. OR not at all. I'm at best +0 on this, > > more like exactly 0. I realize that in practice this kills the idea. > > The "purist" argument for it would have worked better if it was made > > 18 years ago. > > Also what happens with "%i" % 3.14 ? We incidentally found a problem > with a script using python 2.5 because apparently the "%" formatting > operator doesn't use "int()" for doing the conversion (to be more specific > if the float is too large for a 32-bit integer then the format operator chokes > while the int() operator returns a long). That's quite a separate issue. Please ses http://bugs.python.org/issue1742669. > Anyway I want just to say that if "implicit" conversion from float > to integer goes away then what happens to formatting conversion ? > Removing that too IMO would break a lot of code and it's IMO very > difficult to help fixing that. The formatting code could assign specific meanings. I suspect though that it was never meant to be possible to use %d with a float -- it just is one of the artifacts of using implicit conversion, and one not well-thought through. Note: >>> "%.0f" % 3.99 '4' >>> "%d" % 3.99 '3' >>> I think the latter is wrong and confusing. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] trunc()
> [Guido] >> There is actually quite an important signal to the reader that is >> present when you see trunc(x) but absent when you see int(x): with >> trunc(x), the implication is that x is a (Real) number. With int(x), >> you can make no such assumption -- x could be a string, or it could be >> a totally different type that happens to define __int__, perhaps a >> custom date/time type (I believe mxDateTime supports this). > > Can I assume that you agree with this? That would be progress. I agree that it provides a cue that that input is Real. I don't agree that that has any value. We had a lot of tools that can accept multiple input types. For instance, float() can accept a string or number. We could do like C and split-out the atof() functionality but that just makes two functions where one would suffice. > Yet another (minor) argument that has always made me uncomfortable > with int() == trunc(): the % operator. I think it's a big improvement > over C that Python's % operator is defined as > > x%y == x - y*floor(x/y) # where / is real division > > rather than C's division, which uses trunc() instead of floor(). In C > this nicely meshes with the definition of int(): you can define x%y as > x - y*(int)(x/y); but not so in Python. I don't want to use this as an > argument for defining int(x) as floor(x), but I do want to point out > that it has always given me a twinge of discomfort. It hasn't bugged me much, but I do understand. > After all that, here's my current proposal: > > - Deprecating int() is pretty radical, I think it would have to > happen in the distant future. OR not at all. I'm at best +0 on this, > more like exactly 0. I realize that in practice this kills the idea. > The "purist" argument for it would have worked better if it was made > 18 years ago. "pretty radical" is what I meant when I said "it's nuts" ;-) This is a major piece of progress. Most of the prior proposal was predicated on int() being deprecated. > - trunc(), round(), floor() and ceil() should all be built-ins, > corresponding to __trunc__, __round__, __floor__ and __ceil__. Then we > have the four standard ways to go from Reals to Integers, which are > properly extensible for folks who write their own number types. (We > can't control how folks implement __round__, but we can document > expected behavior -- that's how we treat __add__ and all other > operators too, after all.) ISTM, you really don't need trunc() in this mix. The ceil() and floor() functions do an excellent job of convering most use cases. The overlap of trunc() and int() just isn't worth it. There's the mental cost of having to explain the difference on day one to every beginner. There's the back end cost of every class that has __int__ also needing to decide whether to provide __trunc__ which will typically be the same thing. In time, I believe it will become self-evident that having both int() and trunc() is a wart. If trunc() goes into 2.6 and 3.0, then we're going to have to live with this for a long time. Purity may suggest that you need trunc(). Practicality says it isn't worth the cost. At least we've made important progress by saving int(). 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] trunc()
On Jan 27, 2008 9:26 AM, Andrea Griffini <[EMAIL PROTECTED]> wrote: > On Jan 27, 2008 5:43 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > > - Deprecating int() is pretty radical, I think it would have to > > happen in the distant future. OR not at all. I'm at best +0 on this, > > more like exactly 0. I realize that in practice this kills the idea. > > The "purist" argument for it would have worked better if it was made > > 18 years ago. > > Also what happens with "%i" % 3.14 ? We incidentally found a problem > with a script using python 2.5 because apparently the "%" formatting > operator doesn't use "int()" for doing the conversion (to be more specific > if the float is too large for a 32-bit integer then the format operator chokes > while the int() operator returns a long). > Anyway I want just to say that if "implicit" conversion from float > to integer goes away then what happens to formatting conversion ? > Removing that too IMO would break a lot of code and it's IMO very > difficult to help fixing that. Well, it seems like it would be as easy to make some formatting conversions raise a warning on float inputs as it would be to make int() do it. But I think you're safe here; it doesn't look like either will be deprecated. -- Namasté, Jeffrey Yasskin http://jeffrey.yasskin.info/ ___ 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] trunc()
[Raymond Hettinger] >> The idea that programmers are confused by int(3.7)-->3 may not be nuts, but >> it doesn't match any experience I've had with any >> programmer, ever. [Christian Heimes] > You haven't been doing newbie support in #python lately. Statements like > Python is rounding wrong are common. Of course, those floating point repr questions are common, but that wasn't the issue here. The trunc() protagonists are contending that the int(f) function will be confused with the round(f, n) function. I've never seen than come up, ever. 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] trunc()
On Jan 27, 2008 5:43 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote: > - Deprecating int() is pretty radical, I think it would have to > happen in the distant future. OR not at all. I'm at best +0 on this, > more like exactly 0. I realize that in practice this kills the idea. > The "purist" argument for it would have worked better if it was made > 18 years ago. Also what happens with "%i" % 3.14 ? We incidentally found a problem with a script using python 2.5 because apparently the "%" formatting operator doesn't use "int()" for doing the conversion (to be more specific if the float is too large for a 32-bit integer then the format operator chokes while the int() operator returns a long). Anyway I want just to say that if "implicit" conversion from float to integer goes away then what happens to formatting conversion ? Removing that too IMO would break a lot of code and it's IMO very difficult to help fixing that. Andrea ___ 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] Organization of ABC modules
On Jan 27, 2008 12:29 AM, Jeroen Ruigrok van der Werven <[EMAIL PROTECTED]> wrote: > This will be a bikeshed argument until Guido speaks out his > preference/decision I guess. > > But isn't it a more common solution to name the base class just Number and > derive from it by means of using Base.Number or something similar? Looks > cleaner to me rather than all these odd looking pre- or suffixes. (I am not > charmed about ABC in the name at all to be honest, doesn't really give me a > Python feeling.) My preference is still *not* to use a naming convention. I just suggested it as a lesser evil compared to segregating all abstract base classes in an "abc" package ghetto. I really don't see why names like "Number" or "MutableSequence" would need any additional help to make the reader see they are abstract. I note that at least for built-in types there will be the naming convention that concrete implementation classes are all lowercase, like int, float, list, namedtuple, defaultdict, and so on, while the ABCs all have a Capitalized[Words] name: Hashable, Number, Real, MutableMapping, etc. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] trunc()
On Jan 26, 2008 11:14 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> >. You may disagree, but that doesn't make it nuts.
>
> Too many thoughts compressed into one adjective ;-)
[snip]
> > I don't think that Excel should be held up as a shining example for
> > Python.
>
> It is simply a datapoint.
[snip]
You're beginning to repeat your argument; none of that was new.
> One other thought: In Python, it has been nice that we have simple type
> coercions using the type name:
> * set(p)-->qcan accept a list, tuple, string, or any iterable and make a
> set
> * int(p)-->q can accept an int, long, float, or string and make an int
> * float(p)-->q can accept an int, long, float, or string and make an int
> * list(p)-->qcan accept a list, tuple, string, or any iterable and make a
> list
> * unicode(p)--> can accept a str, buffer, or unicode object and make a
> unicode object
> It's a bit weird to decide that int() needs to lose that capability so we get
> generalized Integrals as output. What's wrong with
> coercion to a concrete type?
Let me get back to you on that.
I first want to point out that you snipped the core of my argument in
the post you otherwise quoted. I will repeat it here because I would
like your explicit reaction:
[Guido]
> There is actually quite an important signal to the reader that is
> present when you see trunc(x) but absent when you see int(x): with
> trunc(x), the implication is that x is a (Real) number. With int(x),
> you can make no such assumption -- x could be a string, or it could be
> a totally different type that happens to define __int__, perhaps a
> custom date/time type (I believe mxDateTime supports this).
Can I assume that you agree with this? That would be progress.
Coming back to your argument that other types have a constructor that
takes all kinds of arguments, I'd like to point out that they all have
restrictions too (except for str()): list() and tuple() only accept
iterables, float() only accepts strings and certain numbers (not
complex), and so on. Taking the latter as an example:
>>> float(0j)
Traceback (most recent call last):
File "", line 1, in
TypeError: can't convert complex to float; use abs(z)
>>>
I think that (eventually) int(0.0) could do something similar:
>>> int(0.0)
Traceback (most recent call last):
File "", line 1, in
TypeError: can't convert float to int; use round(x) or trunc(x)
>>>
But see below.
Yet another (minor) argument that has always made me uncomfortable
with int() == trunc(): the % operator. I think it's a big improvement
over C that Python's % operator is defined as
x%y == x - y*floor(x/y) # where / is real division
rather than C's division, which uses trunc() instead of floor(). In C
this nicely meshes with the definition of int(): you can define x%y as
x - y*(int)(x/y); but not so in Python. I don't want to use this as an
argument for defining int(x) as floor(x), but I do want to point out
that it has always given me a twinge of discomfort.
FInally, there's the "one way" argument. That's a nice slogan, but
doesn't really hold anyways in practice. To copy a list, we can write
either L[:] or list(L). To get the keys of a dict, we can write either
D.keys() or list(D). To convert a number to a string we can write
either "%g" % X or str(X). For octal we can write "%#o" % X or oct(X).
To convert a unicode string to UTF-8, we can write either
U.encode("utf8") or str(U, "utf8"). And so on. In many cases, these
notations aren't exactly the same in semantics (e.g. list(X) always
returns a list, X[:] returns whatever sequence type X is), but
nevertheless they have large areas of overlap. This is how I see
trunc() and int() live together.
After all that, here's my current proposal:
- Deprecating int() is pretty radical, I think it would have to
happen in the distant future. OR not at all. I'm at best +0 on this,
more like exactly 0. I realize that in practice this kills the idea.
The "purist" argument for it would have worked better if it was made
18 years ago.
- trunc(), round(), floor() and ceil() should all be built-ins,
corresponding to __trunc__, __round__, __floor__ and __ceil__. Then we
have the four standard ways to go from Reals to Integers, which are
properly extensible for folks who write their own number types. (We
can't control how folks implement __round__, but we can document
expected behavior -- that's how we treat __add__ and all other
operators too, after all.)
- In the docs (especially for beginners) we recommend that users write
trunc() instead of int(), emphasizing that trunc() ensures the
argument is a number, while suggesting int(x) for conversion from
strings. But the implementation won't chastise users by issuing
annoying warnings.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.
Re: [Python-Dev] trunc()
Raymond Hettinger wrote: > The idea that programmers are confused by int(3.7)-->3 may not be nuts, but > it doesn't match any experience I've had with any > programmer, ever. You haven't been doing newbie support in #python lately. Statements like Python is rounding wrong are common. ;) It's astonishing how many major rounding and division bugs are found by newbies. Christian ___ 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] Organization of ABC modules
-On [20080127 03:25], Terry Reedy ([EMAIL PROTECTED]) wrote: >I *think* I would prefer to any of these either >ANumber or >aNumber, >which one can read as either an abbreviation of Abstract Number or simply a >contraction of 'a Number' (a Real, an Integral, etc) taken to mean the >abstraction. This will be a bikeshed argument until Guido speaks out his preference/decision I guess. But isn't it a more common solution to name the base class just Number and derive from it by means of using Base.Number or something similar? Looks cleaner to me rather than all these odd looking pre- or suffixes. (I am not charmed about ABC in the name at all to be honest, doesn't really give me a Python feeling.) -- Jeroen Ruigrok van der Werven / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ We have met the enemy and they are ours... ___ 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] trunc()
On Jan 26, 2008 11:14 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > The idea that programmers are confused by int(3.7)-->3 may not be nuts, but > it doesn't match any experience I've had with any > programmer, ever. In C, I'm pretty sure I've seen people write (long)x where they'd have been better off with lround(x). They know that the cast truncates, and generally that they actually wanted to round, but the type they wanted to get to was foremost in their mind, so they didn't bother to think about it a little and write what they really wanted. It's not that they're confused; it's that they're accepting a default that shouldn't be a default. Your other points seem to have been answered already, although people will disagree on how compelling the answers are, so I won't repeat them here. -- Namasté, Jeffrey Yasskin ___ 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
