Re: [Python-ideas] Fwd: Trigonometry in degrees

[Tim Peters]

[Steven D'Aprano ]

> Thanks Tim!
>

You're welcome ;-)


> Reading your digressions on the minutia of floating point maths is
> certainly an education. It makes algebra and real-valued mathematics
> seem easy in comparison.
>

Hard to say, really.  The problem with floating point is that it's so
God-awful lumpy - special cases all over the place.  Signaling and quiet
NaNs; signed infinities; signed zeroes; normal finites all with the same
number of bits, but where the gap between numbers changes abruptly at
power-of-2 boundaries; subnormals where the gap remains the same across
power-of-2 boundaries, but the number of _bits_ changes abruptly; all "the
rules" break down when you get too close to overflow or underflow; four
rounding modes to worry about; and a whole pile of technically defined
exceptional conditions and related traps & flags.

Ignoring all that, though, it's pretty easy ;-)  754 was dead serious about
requiring results act is if a single rounding is done to the infinitely
precise result, and that actually allows great simplification in reasoning.

The trend these days appears to be using automated theorem-proving systems
to keep track of the mountain of interacting special cases.  Those have
advanced enough that we may even be on the edge of getting
provably-correctly-rounded transcendental functions with reasonable speed.
Although it's not clear people will be able to understand the proofs ;-)

I still haven't got over Mark Dickinson's demonstration a few years
> back that under Decimal floating point, but not binary, it is possible
> for the ordinary arithmetic average (x+y)/2 to be outside of the
> range [x, y]:
>
> py> from decimal import getcontext, Decimal
> py> getcontext().prec = 3
> py> x = Decimal('0.516')
> py> y = Decimal('0.518')
> py> (x + y) / 2
> Decimal('0.515')
>

Ya, decimal fp doesn't really solve anything except the shallow surprise
that decimal fractions generally aren't exactly representable as binary
fractions.  Which is worth a whole lot for casual users, but doesn't
address any of the deep problems (to the contrary, it makes those a bit
worse).

I like to illustrate the above with 1-digit decimal fp, because it makes it
more apparent at once that - unlike as in binary fp - multiplication and
division by 2 may _not_ be exact in decimal fp.  We can't even average a
number "with itself" reliably:

>>> import decimal
>>> decimal.getcontext().prec = 1
>>> x = y = decimal.Decimal(8); (x+y)/2 # 10 is much bigger than 8
Decimal('1E+1')
>>> x = y = decimal.Decimal(7); (x+y)/2 # 5 is much smaller than 7
Decimal('5')

But related things _can_ happen in binary fp too!  You have to be near the
edge of representable non-zero finites though:

>>> x = y = 1e308
>>> x
1e+308
>>> (x+y)/2
inf

Oops.  So rewrite it:

>>> x/2 + y/2
1e+308

Better!  But then:

>>> x = y = float.fromhex("3p-1074")
>>> x
1.5e-323
>>> x/2 + y/2
2e-323

Oops.  A math library has to deal with everything "correctly".  Believe it
or not, this paper

"How do you compute the midpoint of an interval?"
https://hal.archives-ouvertes.fr/hal-00576641v1/document

is solely concerned with computing the average of two IEEE doubles, yet
runs to 29(!) pages.  Almost everything you try fails for _some_ goofy
cases.

I personally write it as (x+y)/2 anyway ;-)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Python Decorator Improvement Idea

[Eric V. Smith]

On 6/16/2018 8:22 PM, Michael Selik wrote:
The idea of having a dunder to introspect the bound variable name has 
been discussed before. You can find the past discussions in the mailing 
list archive. If I recall correctly, there were very few use cases 
beyond namedtuple. With dataclasses available in 3.7, there may be even 
less interest than before.


One such thread is here:
https://mail.python.org/pipermail/python-ideas/2011-March/009250.html

Eric




On Sat, Jun 16, 2018, 9:04 AM Brian Allen Vanderburg II via Python-ideas 
mailto:python-ideas@python.org>> wrote:



On 06/16/2018 01:22 AM, Steven D'Aprano wrote:
 > Some of the information would be available in all
 >> contexts, while other information may only be available in certain
 >> contexts.The parameter's value cannot be explicitly specified,
defaults
 >> to Null except when called as a decorator, and can only be specified
 >> once in the function's parameter list.
 > Do you mean None?

Yes, I meant None instead of Null.

 > [...]
 >> Rules:
 >>
 >> 1. It is not possible for the parameter's value to be directly
 >> specified. You can't call fn(info=...)
 > That sounds like a recipe for confusion to me. How would you explain
 > this to a beginner?
 >
 > Aside from the confusion that something that looks like a parameter
 > isn't an actual parameter, but something magical, it is also very
 > limiting. It makes it more difficult to use the decorator, since
now it
 > only works using @ syntax.

That was just an initial idea.  However there would be no reason
that the
parameter could not be passed directly.  Actually if creating one
decorator
that wraps another decorator, being able to pass the parameter on could
be needed.

Also, the decorator would still work in normal syntax, only with that
parameter
set to None

 >> Information that could be contained in the parameters for all
contexts:
 >>
 >> Variable name
 >> Module object declared in
 >> Module globals (useful for @export/@public style decorators)
 >> Etc
 > The variable name is just the name of the function or class, the
first
 > parameter received by the decorator. You can get it with
func.__name__.

This works with functions and classes but not other values that may
not have __name__.
 >> Using the decorator in a class context, pass the class object.
 > The decorator already receives the class object as the first
parameter.
 > Why pass it again?
 >
 >
 >> While the class object hasn't been fully created yet,
 > What makes you say that?

What I mean is used inside the body of a class to decorate a class
member:

     class MyClass(object):
         @decorator
         def method(self):
             pass

Using the explicit is better than implicit:

     class MyClass(object):
         @decorator(MyClass, ...)
         def method(self):
             pass

However right now that does not work as MyClass does not exist when the
decorator is called.  I'm not sure how Python works on this under
the hood
as it's been a long time since I've looked through the source code.  If
Python
gather's everything under MyClass first before it even begins to
create the
MyClass object, then it may not be possible, but if Python has already
created
a class object, and just not yet assigned it to the MyClass name in the
module,
then perhaps there could be some way to pass that class object to the
decorator.

I have seen some examples that decorates the class and members to
achieve
something similar

     @outerdecorator
     class MyClass:
         @decorator
         def method(self):
             pass

 >
 >>     # This will call the decorator passing in 200 as the object, as
 >>     # well as info.name  as the variable being
assigned.
 >>     @expose
 >>     SCRIPT_CONSTANT = 200
 > That would require a change to syntax, and would have to be a
separate
 > discussion.
 >
 > If there were a way to get the left hand side of assignments as a
 > parameter, that feature would be *far* to useful to waste on just
 > decorators. For instance, we could finally do something about:
 >
 > name = namedtuple("name", fields)

Agreed it would be a change in syntax.  Using the decorator syntax i've
mentioned
the name being assigned would be passed to that extra info parameter.
Python
would treat anything in the form of:

     @decorator
     NAME = (expression)

as a decorator as well:

     _tmp = (expression)
     NAME = decorator(_tmp)

Right now, there's litlte use as it is just as easy to say directly

     NAME = decorator(expression)

With this idea, it could 

Re: [Python-ideas] Python Decorator Improvement Idea

[Michael Selik]

The idea of having a dunder to introspect the bound variable name has been
discussed before. You can find the past discussions in the mailing list
archive. If I recall correctly, there were very few use cases beyond
namedtuple. With dataclasses available in 3.7, there may be even less
interest than before.


On Sat, Jun 16, 2018, 9:04 AM Brian Allen Vanderburg II via Python-ideas <
python-ideas@python.org> wrote:

>
> On 06/16/2018 01:22 AM, Steven D'Aprano wrote:
> > Some of the information would be available in all
> >> contexts, while other information may only be available in certain
> >> contexts.The parameter's value cannot be explicitly specified, defaults
> >> to Null except when called as a decorator, and can only be specified
> >> once in the function's parameter list.
> > Do you mean None?
>
> Yes, I meant None instead of Null.
>
> > [...]
> >> Rules:
> >>
> >> 1. It is not possible for the parameter's value to be directly
> >> specified. You can't call fn(info=...)
> > That sounds like a recipe for confusion to me. How would you explain
> > this to a beginner?
> >
> > Aside from the confusion that something that looks like a parameter
> > isn't an actual parameter, but something magical, it is also very
> > limiting. It makes it more difficult to use the decorator, since now it
> > only works using @ syntax.
>
> That was just an initial idea.  However there would be no reason that the
> parameter could not be passed directly.  Actually if creating one decorator
> that wraps another decorator, being able to pass the parameter on could
> be needed.
>
> Also, the decorator would still work in normal syntax, only with that
> parameter
> set to None
>
> >> Information that could be contained in the parameters for all contexts:
> >>
> >> Variable name
> >> Module object declared in
> >> Module globals (useful for @export/@public style decorators)
> >> Etc
> > The variable name is just the name of the function or class, the first
> > parameter received by the decorator. You can get it with func.__name__.
>
> This works with functions and classes but not other values that may
> not have __name__.
> >> Using the decorator in a class context, pass the class object.
> > The decorator already receives the class object as the first parameter.
> > Why pass it again?
> >
> >
> >> While the class object hasn't been fully created yet,
> > What makes you say that?
>
> What I mean is used inside the body of a class to decorate a class member:
>
> class MyClass(object):
> @decorator
> def method(self):
> pass
>
> Using the explicit is better than implicit:
>
> class MyClass(object):
> @decorator(MyClass, ...)
> def method(self):
> pass
>
> However right now that does not work as MyClass does not exist when the
> decorator is called.  I'm not sure how Python works on this under the hood
> as it's been a long time since I've looked through the source code.  If
> Python
> gather's everything under MyClass first before it even begins to create the
> MyClass object, then it may not be possible, but if Python has already
> created
> a class object, and just not yet assigned it to the MyClass name in the
> module,
> then perhaps there could be some way to pass that class object to the
> decorator.
>
> I have seen some examples that decorates the class and members to achieve
> something similar
>
> @outerdecorator
> class MyClass:
> @decorator
> def method(self):
> pass
>
> >
> >> # This will call the decorator passing in 200 as the object, as
> >> # well as info.name as the variable being assigned.
> >> @expose
> >> SCRIPT_CONSTANT = 200
> > That would require a change to syntax, and would have to be a separate
> > discussion.
> >
> > If there were a way to get the left hand side of assignments as a
> > parameter, that feature would be *far* to useful to waste on just
> > decorators. For instance, we could finally do something about:
> >
> > name = namedtuple("name", fields)
>
> Agreed it would be a change in syntax.  Using the decorator syntax i've
> mentioned
> the name being assigned would be passed to that extra info parameter.
> Python
> would treat anything in the form of:
>
> @decorator
> NAME = (expression)
>
> as a decorator as well:
>
> _tmp = (expression)
> NAME = decorator(_tmp)
>
> Right now, there's litlte use as it is just as easy to say directly
>
> NAME = decorator(expression)
>
> With this idea, it could be possible to do something like this:
>
> def NamedTuple(obj @info):
> return namedtuple(info.name, obj)
>
> @NamedTuple
> Point3 = ["x", "y", "z"]
> >> The two potential benefits I see from this are:
> >>
> >> 1. The runtime can pass certain information to the decorator, some
> >> information in all contexts, and some information in specific contexts
> >> such as when decorating a class member, decorating a function defined
> >> within another 

Re: [Python-ideas] Operator for inserting an element into a list

[Steven D'Aprano]

On Sat, Jun 16, 2018 at 08:21:42PM +0300, Mikhail V wrote:

> For example, such code:
> 
> L = []
> L[] = x
> L[] = y

Should be written as L = [x, y].

> imo has more chance to be understood correctly than e.g.:
> 
> L = []
> L ^= x
> L ^= y

I disagree. The first syntax L[] = x looks so similar to L[:] assignment 
that I keep reading it as "set the list L to a single item x". It 
certainly doesn't look like an append operation.

The second at least looks like a mutation on L.

 
> By L[] there is some mnemonical hint because [] is used to create
> new empty list.

How is that a hint? What is the connection between "append an item" and 
"create a new empty list"?


> So if L[] is found somwhere far from initialisation - it may be a good aid.
> It makes it more clear what is happening, compared to augmented operator.

I don't think so.

Here is a radical thought... why don't we give lists a method that 
inserts items at the end of the list? We could call it something like 
"append", and then instead of hoping people guess what the syntax does, 
they can just look up the name of the method?

L.append(x)

might work.

*wink*





-- 
Steve
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Operator for inserting an element into a list

[Cameron Simpson]

On 16Jun2018 20:21, Mikhail V  wrote:

On Sat, Jun 16, 2018 at 4:44 AM, Cameron Simpson  wrote:

On 16Jun2018 02:42, Mikhail V  wrote:
Some things _should_ be syntax errors. Particularly things which may be
typing errors. Suppose I'd meant to type:

 L[0] = item

Silent breakage, requiring runtime debugging.


Not sure that it's different from any other situation:


Well, many typing errors are invalid syntax. When that happens you find out 
immediately.



e.g. if by mistake I will write:
   L[i+1]   instead of
   L[i+2]


This is true: many other typing errors are not syntax errors.


Visual difference between
   L[] =
   L[1] =

is big enough to reduce the typing error. But maybe I did not
understand your example case.


No, you understand the example; we differ in our estimation of likelihoods and 
costs to mistakes.


Particularly, I dislike "silent breakage", which aan be much harder to fix 
because it shows as incorrect behaviour far from the error (eg counters being 
slightly wrong leading to misbehaviour in things depending on the counter).  
Assuming we are lucky enough for the misbehaviour to be obvious.


But there is also the point that _every_ new piece of syntax reduces the 
surface of "invalid syntax that can catch simple mistakes". So new syntax tends 
to requires a higher perceived benefit than, say, a new feature on a 
class/type. Such as your suggestions about having lists support more operators 
i.e. "^" to mediate list insertion.



FWIW in general, claims about possible typing errors by
introducing this or that syntax are speculative.


Certainly.


Main source of typos usually is high similarity of spellings and
characters, or initial obscurity of spelling - e.g. excessive
punctuation. Does it apply here?


Unsure, depends on the programer.


I understand this is totally different approach than operator
overloading and maybe
hard to implement, but I feel like it looks really appealing.
And it is quite intuitive imo. For me the syntax reads like:
"add new empty element and this element will be "item".


The term "new empty element" is a nonsense term to me.

If you mean "replace an empty slice at the end of the list with a new
element", that can already be written:


I just say that I find this syntax is more intuitive than the idea
with operator. Not sure that we need to start semantics nitpicking.

For example, such code:

   L = []
   L[] = x
   L[] = y


Well, as someone else pointed out, PHP has this notation for append. It is 
quite convenient. (In fact, it is one of the very few convenient things in 
PHP.)


However, PHP is generally not a winning source of ideas in the Python world.  
Certainly I was _very_ glad to not be suffering with PHP once I left my 
previous job. There were many many things to like about my previous job, but 
PHP was not one of them.


Cheers,
Cameron Simpson 
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Operator for inserting an element into a list

[Michael Selik]

On Sat, Jun 16, 2018, 10:22 AM Mikhail V  wrote:
> Plus it does not introduce overloading of the operator.

Now you're critizing duck typing.

And overloading has weakness in this - e.g. " var1 += var2 " does not
> have mnemonics, other than + character (it could be two integers as well).
>

That's an advantage, not disadvantage.

>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Operator for inserting an element into a list

[Mikhail V]

On Sat, Jun 16, 2018 at 4:44 AM, Cameron Simpson  wrote:
> On 16Jun2018 02:42, Mikhail V  wrote:
>>

> Some things _should_ be syntax errors. Particularly things which may be
> typing errors. Suppose I'd meant to type:
>
>  L[0] = item
>
> Silent breakage, requiring runtime debugging.

Not sure that it's different from any other situation:
e.g. if by mistake I will write:

L[i+1]   instead of
L[i+2]

Visual difference between

L[] =
L[1] =

is big enough to reduce the typing error. But maybe I did not
understand your example case.
FWIW in general, claims about possible typing errors by
introducing this or that syntax are speculative.
Main source of typos usually is high similarity of spellings and
characters, or initial obscurity of spelling - e.g. excessive
punctuation. Does it apply here?


>> I understand this is totally different approach than operator
>> overloading and maybe
>> hard to implement, but I feel like it looks really appealing.
>> And it is quite intuitive imo. For me the syntax reads like:
>> "add new empty element and this element will be "item".
>
>
> The term "new empty element" is a nonsense term to me.
>
> If you mean "replace an empty slice at the end of the list with a new
> element", that can already be written:

I just say that I find this syntax is more intuitive than the idea
with operator. Not sure that we need to start semantics nitpicking.

For example, such code:

L = []
L[] = x
L[] = y

imo has more chance to be understood correctly than e.g.:

L = []
L ^= x
L ^= y

By L[] there is some mnemonical hint because [] is used to create
new empty list. Plus it does not introduce overloading of the operator.

And overloading has weakness in this - e.g. " var1 += var2 " does not
have mnemonics, other than + character (it could be two integers as well).

So if L[] is found somwhere far from initialisation - it may be a good aid.
It makes it more clear what is happening, compared to augmented operator.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Python Decorator Improvement Idea

[Brian Allen Vanderburg II via Python-ideas]

On 06/16/2018 01:22 AM, Steven D'Aprano wrote:
> Some of the information would be available in all
>> contexts, while other information may only be available in certain
>> contexts.The parameter's value cannot be explicitly specified, defaults
>> to Null except when called as a decorator, and can only be specified
>> once in the function's parameter list.
> Do you mean None?

Yes, I meant None instead of Null.

> [...]
>> Rules:
>>
>> 1. It is not possible for the parameter's value to be directly
>> specified. You can't call fn(info=...)
> That sounds like a recipe for confusion to me. How would you explain 
> this to a beginner?
>
> Aside from the confusion that something that looks like a parameter 
> isn't an actual parameter, but something magical, it is also very 
> limiting. It makes it more difficult to use the decorator, since now it 
> only works using @ syntax.

That was just an initial idea.  However there would be no reason that the
parameter could not be passed directly.  Actually if creating one decorator
that wraps another decorator, being able to pass the parameter on could
be needed.

Also, the decorator would still work in normal syntax, only with that
parameter
set to None

>> Information that could be contained in the parameters for all contexts:
>>
>> Variable name
>> Module object declared in
>> Module globals (useful for @export/@public style decorators)
>> Etc
> The variable name is just the name of the function or class, the first 
> parameter received by the decorator. You can get it with func.__name__.

This works with functions and classes but not other values that may
not have __name__.
>> Using the decorator in a class context, pass the class object.
> The decorator already receives the class object as the first parameter. 
> Why pass it again?
>
>
>> While the class object hasn't been fully created yet,
> What makes you say that?

What I mean is used inside the body of a class to decorate a class member:

    class MyClass(object):
        @decorator
        def method(self):
            pass

Using the explicit is better than implicit:

    class MyClass(object):
        @decorator(MyClass, ...)
        def method(self):
            pass

However right now that does not work as MyClass does not exist when the
decorator is called.  I'm not sure how Python works on this under the hood
as it's been a long time since I've looked through the source code.  If
Python
gather's everything under MyClass first before it even begins to create the
MyClass object, then it may not be possible, but if Python has already
created
a class object, and just not yet assigned it to the MyClass name in the
module,
then perhaps there could be some way to pass that class object to the
decorator.

I have seen some examples that decorates the class and members to achieve
something similar

    @outerdecorator
    class MyClass:
        @decorator
        def method(self):
            pass

>
>>     # This will call the decorator passing in 200 as the object, as 
>> # well as info.name as the variable being assigned.
>> @expose
>> SCRIPT_CONSTANT = 200
> That would require a change to syntax, and would have to be a separate 
> discussion.
>
> If there were a way to get the left hand side of assignments as a 
> parameter, that feature would be *far* to useful to waste on just 
> decorators. For instance, we could finally do something about:
>
> name = namedtuple("name", fields)

Agreed it would be a change in syntax.  Using the decorator syntax i've
mentioned
the name being assigned would be passed to that extra info parameter. 
Python
would treat anything in the form of:

    @decorator
    NAME = (expression)

as a decorator as well:

    _tmp = (expression)
    NAME = decorator(_tmp)

Right now, there's litlte use as it is just as easy to say directly

    NAME = decorator(expression)

With this idea, it could be possible to do something like this:

    def NamedTuple(obj @info):
        return namedtuple(info.name, obj)

    @NamedTuple
    Point3 = ["x", "y", "z"]
>> The two potential benefits I see from this are:
>>
>> 1. The runtime can pass certain information to the decorator, some
>> information in all contexts, and some information in specific contexts
>> such as when decorating a class member, decorating a function defined
>> within another function, etc
>>
>> 2. It would be possible to decorate values directly, as the runtime can
>> pass relevant information such as the variables name
> No, that would require a second, independent change.
>
> We could, if desired, allow decorator syntax like this:
>
> @decorate
> value = 1
>
> but it seems pretty pointless since that's the same as:
>
> value = decorator(1)
>
> The reason we have @decorator syntax is not to be a second way to call 
> functions, using two lines instead of a single expression, but to avoid 
> having to repeat the name of the function three times:
>
> # Repeat the function name three times:
> def function():
>

Re: [Python-ideas] Fwd: Trigonometry in degrees

[Steven D'Aprano]

On Thu, Jun 14, 2018 at 01:44:34PM -0500, Tim Peters wrote:
> I should note that numeric code "that works" is often much subtler than it
> appears at first glance.  So, for educational purposes, I'll point out some
> of what _wasn't_ said about this crucial function:
[...]


Thanks Tim!

Reading your digressions on the minutia of floating point maths is 
certainly an education. It makes algebra and real-valued mathematics 
seem easy in comparison.

I still haven't got over Mark Dickinson's demonstration a few years 
back that under Decimal floating point, but not binary, it is possible 
for the ordinary arithmetic average (x+y)/2 to be outside of the 
range [x, y]:


py> from decimal import getcontext, Decimal
py> getcontext().prec = 3
py> x = Decimal('0.516')
py> y = Decimal('0.518')
py> (x + y) / 2
Decimal('0.515')




-- 
Steve
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Operator for inserting an element into a list

[Chris Angelico]

On Sat, Jun 16, 2018 at 9:09 PM, Steven D'Aprano  wrote:
> On Sat, Jun 16, 2018 at 01:06:45PM +1200, Greg Ewing wrote:
>> Michael Selik wrote:
>> >The += operator was meant as an alias for ``x = x + 1``. The
>> >fact that it mutates a list is somewhat of a surprise.
>>
>> That's very much a matter of opinion. For every person who
>> thinks this is a surprise, you can find another that thinks
>> it's obvious that += should mutate a list, and is surprised
>> by the fact that it works on immutable types at all.
>
> Given the ubiquity of += in C, where it works on numbers but not lists,
> and the general difficulty many people have in dealing with the
> difference between assignment and mutation, I think the ratio would be
> closer to 20:1 than 1:1.

The nearest you'd get to "adding to a list/array" in C would be adding
to a pointer. But I don't see people writing code like this in Python:

>>> x = [10, 20, 30, 40]
>>> x += 1
>>> assert x == [20, 30, 40]

:)

> But regardless, I'm pretty sure that nobody expects this:
>
>
> py> t = ([], None)
> py> t[0] += [1]
> Traceback (most recent call last):
>   File "", line 1, in 
> TypeError: 'tuple' object does not support item assignment
> py> print(t)
> ([1], None)
>

Agreed, although I can't remember this ever coming up outside of
interactive work. When you do something at the interactive prompt, you
can kinda feel that it should "rollback" on exception, and yet some
part of it has happened. But in most scripts, that TypeError is going
to pull you all the way out of the scope where 't' exists -
frequently, it'll just straight-up terminate the script - so you won't
often see this.

ChrisA
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Approximately equal operator

[Chris Angelico]

On Sat, Jun 16, 2018 at 8:51 PM, Steven D'Aprano  wrote:
>> Python is *very* stingy with adding new operators; IIRC only 3 have
>> been added over the last ~30 years (**, //, @). I don't think ~= is
>> going to make it.
>
> Exponentiation ** goes back to Python 1.5, so I think that's only two
> new operators :-)
>

I'm not sure if they count or not, but 'await' and 'yield' are kinda
like unary operators. But yeah, the language is deliberately stingy
there.

ChrisA
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Operator for inserting an element into a list

[Steven D'Aprano]

On Sat, Jun 16, 2018 at 01:06:45PM +1200, Greg Ewing wrote:
> Michael Selik wrote:
> >The += operator was meant as an alias for ``x = x + 1``. The 
> >fact that it mutates a list is somewhat of a surprise.
> 
> That's very much a matter of opinion. For every person who
> thinks this is a surprise, you can find another that thinks
> it's obvious that += should mutate a list, and is surprised
> by the fact that it works on immutable types at all.

Given the ubiquity of += in C, where it works on numbers but not lists, 
and the general difficulty many people have in dealing with the 
difference between assignment and mutation, I think the ratio would be 
closer to 20:1 than 1:1.

But regardless, I'm pretty sure that nobody expects this:


py> t = ([], None)
py> t[0] += [1]
Traceback (most recent call last):
  File "", line 1, in 
TypeError: 'tuple' object does not support item assignment
py> print(t)
([1], None)


> surprised by at least one of its meanings. :-)
> 
> Maybe we should call it the "Spanish Inquisition operator".

:-)


-- 
Steve
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] [issue33865] [EASY] Missing code page aliases: "unknown encoding: 874"

[Steven D'Aprano]

> It is easy to test it. Encoding/decoding with '874' should give the 
> same result as with 'cp874'.

I know it is too late to remove that feature, but why do we support 
digit-only IDs for encodings? They can be ambiguous. If Wikipedia is 
correct, cp874 (also known as ibm874) and Windows-874 (also known as 
cp1162) are different:

https://en.wikipedia.org/wiki/ISO/IEC_8859-11#Code_page_874

https://en.wikipedia.org/wiki/ISO/IEC_8859-11#Code_page_1162


-- 
Steve
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Approximately equal operator

[Steven D'Aprano]

On Fri, Jun 15, 2018 at 05:31:57PM -0700, Nathaniel Smith wrote:
> On Fri, Jun 15, 2018 at 3:56 PM, Andre Roberge  
> wrote:
> > * people doing heavy numerical work and wanting code as readable as possible
> 
> IME serious numerical work doesn't use approximate equality tests at
> all, except in test assertions.

I wouldn't go that far. It is quite common to write

abs(x - y) < e

or similar, to see whether x and y are within a certain distance of each 
other. APL even made their equals operator an "approximate equality" 
operator. So I don't think it is completely crazy to want an operator 
for this. But I think that falls short of "a good idea for Python".


> > * teaching mostly beginners about finite precision for floating point
> > arithmetics
> 
> Given that approximate equality tests are almost never the right
> solution, I would be worried that emphasizing them to beginners would
> send them down the wrong path. This is already a common source of
> confusion and trap for non-experts.

Certainly it is an area that is rife with superstitition, like the idea 
that you should "never" compare two floats for equality, or folklore 
about what tolerance you should use.

https://randomascii.wordpress.com/2012/02/25/comparing-floating-point-numbers-2012-edition/


> > * people wishing to have trigonometric functions with arguments in degrees,
> > as in a current discussion on this forum.
> 
> AFAICT approximate equality checks aren't really useful for that, no.

Indeed. The last thing a maths library should be doing is making 
arbitrary choices that some value is "close enough" and return "the 
value we think you want".

"Hi, the number you gave is pretty close to 60°, so I'm going to round 
the answer off whether you want me to or not."

Its okay for people to make their own determination what "close enough" 
means, and for many purposes 0.99 could be close enough to 1. But the 
library shouldn't.


[...]
> Python is *very* stingy with adding new operators; IIRC only 3 have
> been added over the last ~30 years (**, //, @). I don't think ~= is
> going to make it.

Exponentiation ** goes back to Python 1.5, so I think that's only two 
new operators :-)



-- 
Steve
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Loosen 'as' assignment

[Nick Coghlan]

On 16 June 2018 at 15:49, Rin Arakaki  wrote:

> Hi,
> I'm wondering if it's possible and consistent that loosen 'as' assignment,
> for example:
>
> >>> import psycopg2 as pg
> >>> import psycopg2.extensions as pg.ex
>
> You can't now assign to an attribute in as statement but are there some
> reasons?
> To be honest, I'll be satisfied if the statement above become valid, but
> also interested in general design decisions about 'as' functionality, I
> mean, it can be applicable to all expression that can be left side of '='
> such as 'list[n]' one, and also other statement than 'import' such as
> 'with'.
>

This is essentially monkeypatching the psycopg2 module to alias the
"extensions" submodule as the "ex" submodule. You can already do that today
as:

>>> import psycopg2 as pg
>>> import psycopg2.extensions
>>> pg.ex = pg.extensions

Monkeypatching other modules at runtime is a questionable enough practice
that we're unlikely to add syntax that actively encourages it.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/