[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
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
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
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
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
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).
>
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
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
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
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
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
>
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,
> 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
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
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
>
15 matches
Mail list logo
