Am 24.09.2011 04:40, schrieb Guido van Rossum:
> On Fri, Sep 23, 2011 at 7:13 PM, Steven D'Aprano wrote:
http://code.activestate.com/recipes/577068-floating-point-range/
>>>
>>> I notice that your examples carefully skirt around the rounding issues.
>>
>> I also carefully *didn't* claim that
On Fri, Sep 23, 2011 at 7:13 PM, Steven D'Aprano wrote:
>>> http://code.activestate.com/recipes/577068-floating-point-range/
>>
>> I notice that your examples carefully skirt around the rounding issues.
>
> I also carefully *didn't* claim that it made rounding issues disappear
> completely. I'll a
Guido van Rossum wrote:
On Fri, Sep 23, 2011 at 6:36 PM, Steven D'Aprano wrote:
Ethan Furman wrote:
A question came up on StackOverflow about range objects and floating point
numbers. I thought about writing an frange that did for floats what range
does for ints,
For what it's worth, here's
On Fri, Sep 23, 2011 at 6:36 PM, Steven D'Aprano wrote:
> Ethan Furman wrote:
>>
>> A question came up on StackOverflow about range objects and floating point
>> numbers. I thought about writing an frange that did for floats what range
>> does for ints,
>
>
> For what it's worth, here's mine:
>
>
Ethan Furman wrote:
A question came up on StackOverflow about range objects and floating
point numbers. I thought about writing an frange that did for floats
what range does for ints,
For what it's worth, here's mine:
http://code.activestate.com/recipes/577068-floating-point-range/
--
S
On Fri, Sep 23, 2011 at 18:49, Terry Reedy wrote:
> A interactive lisp interpreter can detect end-of-statement without a blank
> line by matching a closing paren to the open paren that starts every
> expression.
Braces-loving programmers around the world are feverishly writing a
PEP as we speak.
On 9/23/2011 7:25 PM, anatoly techtonik wrote:
Currently if you work in console and define a function and then
immediately call it - it will fail with SyntaxError.
For example, copy paste this completely valid Python script into console:
def some():
print "XXX"
some()
There is an issue for t
I agree that it should and it doesn't. I also recall that not having empty
lines between function/class definitions can cause indentation errors when
pasting to the console on my windows machine.
--Yuval
On Sep 23, 2011 7:26 PM, "anatoly techtonik" wrote:
> Currently if you work in console and de
On Fri, Sep 23, 2011 at 4:25 PM, anatoly techtonik wrote:
> Currently if you work in console and define a function and then
> immediately call it - it will fail with SyntaxError.
> For example, copy paste this completely valid Python script into console:
>
> def some():
> print "XXX"
> some()
>
>
Currently if you work in console and define a function and then
immediately call it - it will fail with SyntaxError.
For example, copy paste this completely valid Python script into console:
def some():
print "XXX"
some()
There is an issue for that that was just closed by Eric. However, I'd
lik
Ethan Furman wrote:
The only reason I'm aware of at the moment is to prevent loss of
functionality from 2.x range to 3.x range.
Since 2.x range(...) is equivalent to 3.x list(range(...)), I don't
see any loss of functionality there.
Comparing range objects directly in 3.x is like comparing xr
Martin v. Löwis wrote:
Yes, I realize this is because range returned a list in 2.x. However,
aren't __contains__, __getitem__, count, and index implemented in 3.x
range because 2.x range returned lists?
No, they are implemented because they are meaningful, and with an
obvious meaning. "Is 30 i
> Yes, I realize this is because range returned a list in 2.x. However,
> aren't __contains__, __getitem__, count, and index implemented in 3.x
> range because 2.x range returned lists?
No, they are implemented because they are meaningful, and with an
obvious meaning. "Is 30 in the range from 10
Le Fri, 23 Sep 2011 13:23:26 -0700,
Ethan Furman a écrit :
>
> So the question becomes, Why does it implement the Sequence ABC?
Because these operations are trivial to implement and it would be
suboptimal to have to instantiate the full list to run them?
_
On Fri, Sep 23, 2011 at 1:23 PM, Ethan Furman wrote:
> The only reason I'm aware of at the moment is to prevent loss of
> functionality from 2.x range to 3.x range.
>
> I'm -0 with a decision to not have range be orderable; but I understand
> there are bigger fish to fry. :)
I don't believe ther
Benjamin Peterson wrote:
2011/9/23 Ethan Furman :
Benjamin Peterson wrote:
2011/9/23 Ethan Furman :
Follow-up question: since the original range returned lists, and
comparisons
do make sense for lists, should the new range also implement them?
What would be the use-case?
The only reason I'm
2011/9/23 Ethan Furman :
> Benjamin Peterson wrote:
>>
>> 2011/9/23 Ethan Furman :
>
>>>
>>>
>>> Follow-up question: since the original range returned lists, and
>>> comparisons
>>> do make sense for lists, should the new range also implement them?
>>
>> What would be the use-case?
>
> The only rea
On 2011-09-23, at 20:23 , Guido van Rossum wrote:
> Also, Ethan, I hope you're familiar with the reason why there is no
> range() support for floats currently? (Briefly, things like range(0.0,
> 0.8, step=0.1) could include or exclude the end point depending on
> rounding, which makes for troubleso
Benjamin Peterson wrote:
2011/9/23 Ethan Furman :
>>
Follow-up question: since the original range returned lists, and comparisons
do make sense for lists, should the new range also implement them?
What would be the use-case?
The only reason I'm aware of at the moment is to prevent loss of
Guido van Rossum wrote:
Also, Ethan, I hope you're familiar with the reason why there is no
range() support for floats currently? (Briefly, things like range(0.0,
0.8, step=0.1) could include or exclude the end point depending on
rounding, which makes for troublesome semantics.)
Good point, tha
Also, Ethan, I hope you're familiar with the reason why there is no
range() support for floats currently? (Briefly, things like range(0.0,
0.8, step=0.1) could include or exclude the end point depending on
rounding, which makes for troublesome semantics.)
On Fri, Sep 23, 2011 at 11:14 AM, Benjamin
2011/9/23 Ethan Furman :
> A question came up on StackOverflow about range objects and floating point
> numbers. I thought about writing an frange that did for floats what range
> does for ints, so started examining the range class. I noticed it has
> __le__, __lt__, __eq__, __ne__, __ge__, and _
A question came up on StackOverflow about range objects and floating
point numbers. I thought about writing an frange that did for floats
what range does for ints, so started examining the range class. I
noticed it has __le__, __lt__, __eq__, __ne__, __ge__, and __gt__
methods. Some experime
On 23/09/2011 20.11, Éric Araujo wrote:
Hi Victor,
diff --git a/Misc/NEWS b/Misc/NEWS
--- a/Misc/NEWS
+++ b/Misc/NEWS
@@ -10,6 +10,10 @@
Core and Builtins
-
+- Issue #7732: Don't open a directory as a file anymore while importing a
+ module. Ignore the direcotry if its nam
Hi Victor,
> diff --git a/Misc/NEWS b/Misc/NEWS
> --- a/Misc/NEWS
> +++ b/Misc/NEWS
> @@ -10,6 +10,10 @@
> Core and Builtins
> -
>
> +- Issue #7732: Don't open a directory as a file anymore while importing a
> + module. Ignore the direcotry if its name matchs the module name (
ACTIVITY SUMMARY (2011-09-16 - 2011-09-23)
Python tracker at http://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open3030 (+11)
closed 21788 (+31)
total 24818 (+42)
Open issues wit
Hi!
On Fri, Sep 23, 2011 at 11:12:53AM -0400, Martin Goudreau wrote:
> Please check a very small
> module i'v made for improving the debugger traceback. See the
> pybettererror.py on sourceforge:
> http://pybettererror.sourceforge.net/projet.html
Why do this in sys.stderr and not by monkey-pat
Hello Dev Teem,
Guido told me to send you this idea...
Improving productivity is one of my Strength. Please check a very small
module i'v made for improving the debugger traceback. See the
pybettererror.py on sourceforge:
http://pybettererror.sourceforge.net/projet.html
It's hard to find somethi
Hi Victor,
> summary:
> Issue #12931: xmlrpclib now encodes Unicode URI to ISO-8859-1, instead of
> failing with a UnicodeDecodeError.
>
> diff --git a/Lib/test/test_xmlrpc.py b/Lib/test/test_xmlrpc.py
> --- a/Lib/test/test_xmlrpc.py
> +++ b/Lib/test/test_xmlrpc.py
> @@ -472,6 +472,9 @@
>
29 matches
Mail list logo
