Re: [Python-Dev] Ancient use of generators

[David Mertz]

I'm glad to see that everything old is new again.  All the stuff being
discussed nowadays, even up through PEP 492, was largely what I was trying
to show in 2002  the syntax just got nicer in the intervening 13 years
:-).

On Wed, May 6, 2015 at 10:57 AM, Guido van Rossum  wrote:

> For those interested in tracking the history of generators and coroutines
> in Python, I just found out that PEP 342
> <https://www.python.org/dev/peps/pep-0342/> (which introduced
> send/throw/close and made "generators as coroutines" a mainstream Python
> concept) harks back to PEP 288 <https://www.python.org/dev/peps/pep-0288/>,
> which was rejected. PEP 288 also proposed some changes to generators. The
> interesting bit though is in the references: there are two links to old
> articles by David Mertz that describe using generators in state machines
> and other interesting and unconventional applications of generators. All
> these well predated PEP 342, so yield was a statement and could not receive
> a value from the function calling next() -- communication was through a
> shared class instance.
>
> http://gnosis.cx/publish/programming/charming_python_b5.txt
> http://gnosis.cx/publish/programming/charming_python_b7.txt
>
> Enjoy!
>
> --
> --Guido van Rossum (python.org/~guido)
>



-- 
Keeping medicines from the bloodstreams of the sick; food
from the bellies of the hungry; books from the hands of the
uneducated; technology from the underdeveloped; and putting
advocates of freedom in prisons.  Intellectual property is
to the 21st century what the slave trade was to the 16th.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Why aren't decorators just expressions?

[David Mertz]

I always realized the restriction was there, and once in a while mention it
in teaching. But I've NEVER had an actual desire to use anything other that
a simple decorator or a "decorator factory" (which I realize is a decorator
in the grammar, but it's worth teaching how to parameterize custom ones,
which is a factory).

I've used barry_as_FLUFL more often, actually... Albeit always joking
around for students, not in production covfefe.

On Sep 16, 2017 9:46 AM, "Barry Warsaw"  wrote:

On Sep 16, 2017, at 02:39, Larry Hastings  wrote:

> I'm not proposing that we allow arbitrary expressions as decorators...
well, I'm not doing that yet at least.  But like I said, the syntax has
been this way for 13 years and I don't recall anybody complaining.

Indeed, I can’t remember a single time where I’ve needed that, let alone
actually realized the restriction existed.  But now that you mention it, I
do remember discussions in favor of the more restricted syntax when the
feature was originally being debated.  I don’t remember the reasons though
- it well could have been an abundance of caution over how far to take the
new syntax (and understanding of course that it’s easier to relax than
restrict).

-Barry


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: https://mail.python.org/mailman/options/python-dev/
mertz%40gnosis.cx
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 564: Add new time functions with nanosecond resolution

[David Mertz]

I worked at a molecular dynamics lab for a number of years. I advocated
switching all our code to using attosecond units (rather than fractional
picoseconds).

However, this had nothing whatsoever to do with the machine clock speeds,
but only with the physical quantities represented and the scaling/rounding
math.

It didn't happen, for various reasons. But if it had, I certainly wouldn't
have expected standard library support for this. The 'time' module is about
wall clock out calendar time, not about *simulation time*.

FWIW, a very long simulation might cover a millisecond of simulated
time we're a very long way from looking at molecular behavior over 104
days.

On Oct 22, 2017 8:10 AM, "Wes Turner"  wrote:



On Saturday, October 21, 2017, Nick Coghlan  wrote:

> On 22 October 2017 at 09:32, Victor Stinner 
> wrote:
>
>> Le 21 oct. 2017 20:31, "francismb"  a écrit :
>>
>> I understand that one can just multiply/divide the nanoseconds returned,
>> (or it could be a factory) but wouldn't it help for future enhancements
>> to reduce the number of functions (the 'pico' question)?
>>
>>
>> If you are me to predict the future, I predict that CPU frequency will be
>> stuck below 10 GHz for the next 10 years :-)
>>
>
> There are actually solid physical reasons for that prediction likely being
> true. Aside from the power consumption, heat dissipation, and EM radiation
> issues that arise with higher switching frequencies, you also start running
> into more problems with digital circuit metastability ([1], [2]): the more
> clock edges you have per second, the higher the chances of an asynchronous
> input changing state at a bad time.
>
> So yeah, for nanosecond resolution to not be good enough for programs
> running in Python, we're going to be talking about some genuinely
> fundamental changes in the nature of computing hardware, and it's currently
> unclear if or how established programming languages will make that jump
> (see [3] for a gentle introduction to the current state of practical
> quantum computing). At that point, picoseconds vs nanoseconds is likely to
> be the least of our conceptual modeling challenges :)
>

There are current applications with greater-than nanosecond precision:

- relativity experiments
- particle experiments

Must they always use their own implementations of time., datetime.
__init__, fromordinal, fromtimestamp ?!

- https://scholar.google.com/scholar?q=femtosecond
- https://scholar.google.com/scholar?q=attosecond
- GPS now supports nanosecond resolution
-

https://en.wikipedia.org/wiki/Quantum_clock#More_accurate_
experimental_clocks

> In 2015 JILA  evaluated the
absolute frequency uncertainty of their latest strontium-87
 optical lattice
clock at 2.1 × 10−18, which corresponds to a measurable gravitational time
dilation  for
an elevation change of 2 cm (0.79 in)

What about bus latency (and variance)?

>From https://www.nist.gov/publications/optical-two-way-
time-and-frequency-transfer-over-free-space :

> Optical two-way time and frequency transfer over free space
> Abstract
> The transfer of high-quality time-frequency signals between remote
locations underpins many applications, including precision navigation and
timing, clock-based geodesy, long-baseline interferometry, coherent radar
arrays, tests of general relativity and fundamental constants, and future
redefinition of the second. However, present microwave-based time-frequency
transfer is inadequate for state-of-the-art optical clocks and oscillators
that have femtosecond-level timing jitter and accuracies below 1 × 10−17.
Commensurate optically based transfer methods are therefore needed. Here we
demonstrate optical time-frequency transfer over free space via two-way
exchange between coherent frequency combs, each phase-locked to the local
optical oscillator. We achieve 1 fs timing deviation, residual instability
below 1 × 10−18 at 1,000 s and systematic offsets below 4 × 10−19, despite
frequent signal fading due to atmospheric turbulence or obstructions across
the 2 km link. This free-space transfer can enable terrestrial links to
support clock-based geodesy. Combined with satellite-based optical
communications, it provides a path towards global-scale geodesy,
high-accuracy time-frequency distribution and satellite-based relativity
experiments.

How much wider must an epoch-relative time struct be for various realistic
time precisions/accuracies?

10-6 micro µ
10-9 nano n -- int64
10-12 pico p
10-15 femto f
10-18 atto a
10-21 zepto z
10-24 yocto y

I'm at a loss to recommend a library to prefix these with the epoch; but
future compatibility may be a helpful, realistic objective.

Natural keys with such time resolution are still unfortunately likely to
collide.


>
> Cheers,
> Nick.
>
> [1] https://en.wikipedia.org/wiki/Metastability_in_electronics
> [2] https

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

[David Mertz]

I strongly opposed adding an ordered guarantee to regular dicts. If the
implementation happens to keep that, great. Maybe OrderedDict can be
rewritten to use the dict implementation. But the evidence that all
implementations will always be fine with this restraint feels poor, and we
have a perfectly good explicit OrderedDict for those who want that.

On Nov 6, 2017 7:39 PM, "Brett Cannon"  wrote:

>
>
> On Mon, 6 Nov 2017 at 11:08 Paul Sokolovsky  wrote:
>
>> Hello,
>>
>> On Mon, 06 Nov 2017 17:58:47 +
>> Brett Cannon  wrote:
>>
>> []
>>
>> > > Why suddenly once in 25 years there's a need to do something to
>> > > dict's, violating computer science background behind them (one of
>> > > the reason enough people loved Python comparing to other "practical
>> > > hack" languages)?
>> >
>> > I don't understand what "computer science background" is being
>> > violated?
>>
>> I tried to explain that in the previous mail, can try a different
>> angle. So, please open you favorite CS book (better few) and look up
>> "abstract data types", then "mapping/associative array" and "list". We
>> can use Wikipedia too: https://en.wikipedia.org/wiki/Associative_array.
>> So, please look up: "Operations associated with this data type allow".
>> And you'll see, that there're no "ordering" related operations are
>> defined. Vice versa, looking at "sequence" operations, there will be
>> "prev/next", maybe "get n'th" element operations, implying ordering.
>>
>
> I don't think you meant for this to come off as insulting, but telling me
> how to look up the definition of an associative array or map feels like
> you're putting me down. I also have a Ph.D. in computer science so I'm
> aware of the academic definitions of these data structures.
>
>
>>
>> Python used to be a perfect application of these principles. Its dict
>> was a perfect CS implementation of an abstract associative array, and
>> list - of "sequence" abstract type (with additional guarantee of O(1)
>> random element access).
>
>
>> People knew and rejoiced that Python is built on solid science
>> principles, or could *learn* them from it.
>
> That no longer will be true,
>> with a sound concept being replaced with on-the-spot practical hack,
>> choosing properties of a random associative array algorithm
>> implementation over properties of a superset of such algorithms (many
>> of which are again don't offer any orderness guarantees).
>>
>>
> I don't think it's fair to call the current dict implementation a hack.
> It's a sound design that has a certain property that we are discussing the
> masking of. As I said previously, I think this discussion comes down to
> whether we think there are pragmatic benefits to exposing the ordered
> aspects to the general developer versus not.
>
> -Brett
>
>
>>
>>
>> I know though what will be replied (based on the replies below): "all
>> these are implementation details" - no, orderness vs non-orderness of a
>> mapping algorithm is an implementation detail; "users shouldn't know all
>> that" - they should, that's the real knowledge, and up until now, they
>> could learn that from *Python docs*, "we can't predict future" - we
>> don't need, we just need to know the past (25 years in our case), and
>> understand why it was done like that, I don't think Guido couldn't code
>> it ordered in 1991, it's just not natural for a mapping type to be so,
>> and in 2017, it's not more natural than it was in 1991.
>
>
>>
>> MicroPython in particular appeared because Python offered all the
>> CS-sound properties and freedom and alternative choices for
>> implementation (more so than any other scripting language). It's losing
>> it, and not just for MicroPython's surprise.
>>
>>
>> []
>>
>>
>> --
>> Best regards,
>>  Paul  mailto:pmis...@gmail.com
>>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> mertz%40gnosis.cx
>
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

[David Mertz]

On Nov 6, 2017 9:11 PM, "Raymond Hettinger" 
wrote:

> On Nov 6, 2017, at 8:05 PM, David Mertz  wrote:
> I strongly opposed adding an ordered guarantee to regular dicts. If the
implementation happens to keep that, great. Maybe OrderedDict can be
rewritten to use the dict implementation. But the evidence that all
implementations will always be fine with this restraint feels poor, and we
have a perfectly good explicit OrderedDict for those who want that.

I think this post is dismissive of the value that users would get from
having reliable ordering by default.


Dismissive seems like an overly strong word. I recognize I disagree with
Raymond on best official semantics. Someone else points out that if someday
an "even more efficient unordered dict" is discovered, user-facing "dict"
doesn't strictly have to be the same data structure as "internal dict". The
fact they are is admittedly an implementation detail also.

I've had all those same uses about round-tripping serialization that
Raymond mentions. I know the standard work arounds (which are not
difficult, but DO require a little extra code if we don't have order).

But like Raymond, I make most of my living TEACHING Python. I feel like the
extra order guarantee would make teaching slightly harder. I'm sure he
feels contrarily. It is true that with 3.6 I can no longer show an example
where the dict display is oddly changed when printed. But then, unordered
sets also wind up sorting small integers on printing, even though that's
not a guarantee.

Ordering by insertion order (possibly "only until first deletion") is
simply not obvious to beginners. If we had, hypothetically, a dict that
"always alphabetized keys" that would be more intuitive to them, for
example. Insertion order feels obvious to us experts, but it really is an
extra cognitive burden to learners beyond understanding "key/Val
association".

Having worked with Python 3.6 for a while, it is repeatedly delightful to
encounter the effects of ordering.  When debugging, it is a pleasure to be
able to easily see what has changed in a dictionary.  When creating XML, it
is joy to see the attribs show in the same order you added them.  When
reading a configuration, modifying it, and writing it back out, it is a
godsend to have it written out in about the same order you originally typed
it in.  The same applies to reading and writing JSON.  When adding a VIA
header in a HTTP proxy, it is nice to not permute the order of the other
headers. When generating url query strings for REST APIs, it is nice have
the parameter order match documented examples.

We've lived without order for so long that it seems that some of us now
think data scrambling is a virtue.  But it isn't.  Scrambled data is the
opposite of human friendly.


Raymond


P.S. Especially during debugging, it is often inconvenient, difficult, or
impossible to bring in an OrderedDict after the fact or to inject one into
third-party code that is returning regular dicts.  Just because we have
OrderedDict in collections doesn't mean that we always get to take
advantage of it.  Plain dicts get served to us whether we want them or not.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Tricky way of of creating a generator via a comprehension expression

[David Mertz]

Inasmuch as I get to opine, I'm +1 on SyntaxError. There is no behavior for
that spelling that I would find intuitive or easy to explain to students.
And as far as I can tell, the ONLY time anything has ever been spelled that
way is in comments saying "look at this weird edge case behavior in Python."

On Nov 22, 2017 10:57 AM, "Jelle Zijlstra"  wrote:



2017-11-22 9:58 GMT-08:00 Guido van Rossum :

> Wow, 44 messages in 4 hours. That must be some kind of record.
>
> If/when there's an action item, can someone summarize for me?
>
> The main disagreement seems to be about what this code should do:

g = [(yield i) for i in range(3)]

Currently, this makes `g` into a generator, not a list. Everybody seems to
agree this is nonintuitive and should be changed.

One proposal is to make it so `g` gets assigned a list, and the `yield`
happens in the enclosing scope (so the enclosing function would have to be
a generator). This was the way things worked in Python 2, I believe.

Another proposal is to make this code a syntax error, because it's
confusing either way. (For what it's worth, that would be my preference.)

There is related discussion about the semantics of list comprehensions
versus calling list() on a generator expression, and of async semantics,
but I don't think there's any clear point of action there.


> --
> --Guido van Rossum (python.org/~guido)
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/jelle.
> zijlstra%40gmail.com
>
>

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: https://mail.python.org/mailman/options/python-dev/
mertz%40gnosis.cx
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Tricky way of of creating a generator via a comprehension expression

[David Mertz]

FWIW, on a side point. I use 'yield' and 'yield from' ALL THE TIME in real
code. Probably 80% of those would be fine with yield statements, but a
significant fraction use `gen.send()`.

On the other hand, I have yet once to use 'await', or 'async' outside of
pedagogical contexts. There are a whole lot of generators, including ones
utilizing state injection, that are useful without the scaffolding of an
event loop, in synchronous code.

Of course, I never use them in comprehensions or generator expressions. And
even after reading every post in this thread, the behavior (either existing
or desired by some) such constructs have is murky and difficult for me to
reason about. I strongly support deprecation or even just immediate
SyntaxError in 3.7.

On Nov 25, 2017 12:38 PM, "Guido van Rossum"  wrote:

> On Sat, Nov 25, 2017 at 12:17 PM Brett Cannon  wrote:
>>
> On Fri, Nov 24, 2017, 19:32 Guido van Rossum,  wrote:
>>>
 On Fri, Nov 24, 2017 at 4:22 PM, Guido van Rossum 
 wrote:

> The more I hear about this topic, the more I think that `await`,
> `yield` and `yield from` should all be banned from occurring in all
> comprehensions and generator expressions. That's not much different from
> disallowing `return` or `break`.
>

 From the responses it seems that I tried to simplify things too far.
 Let's say that `await` in comprehensions is fine, as long as that
 comprehension is contained in an `async def`. While we *could* save `yield
 [from]` in comprehensions, I still see it as mostly a source of confusion,
 and the fact that the presence of `yield [from]` *implicitly* makes the
 surrounding `def` a generator makes things worse. It just requires too many
 mental contortions to figure out what it does.

 I still propose to rule out all of the above from generator
 expressions, because those can escape from the surrounding scope.

>>>
>>> +1 from me
>>>
>>
> On Sat, Nov 25, 2017 at 9:21 AM, Yury Selivanov 
> wrote:
>
>> So we are keeping asynchronous generator expressions as long as they are
>> defined in an 'async def' coroutine?
>>
>
> I would be happy to declare that `await` is out of scope for this thread.
> It seems that it is always well-defined and sensible what it does in
> comprehensions and in genexprs. (Although I can't help noticing that PEP
> 530 does not appear to propose `await` in generator expressions -- it
> proposes `async for` in comprehensions and in genexprs, and `await` in
> comprehensions only -- but they appear to be accepted nevertheless.)
>
> So we're back to the original issue, which is that `yield` inside a
> comprehension accidentally makes it become a generator rather than a list,
> set or dict. I believe that this can be fixed. But I don't believe we
> should fix it. I believe we should ban `yield` from comprehensions and from
> genexprs. We don't need it, and it's confused most everyone. And the ban
> should extend to `yield from` in those same contexts. I think we have a
> hope for consensus on this.
>
> (I also think that if we had invented `await` earlier we wouldn't have
> gone down the path of `yield` expressions -- but historically it appears we
> wouldn't have invented `await` at all if we hadn't first tried `yield` and
> then `yield from` to build coroutines, so I don't think this so bad after
> all. :-)
>
> --
> --Guido van Rossum (python.org/~guido)
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> mertz%40gnosis.cx
>
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Tricky way of of creating a generator via a comprehension expression

[David Mertz]

On Sat, Nov 25, 2017 at 3:37 PM, Guido van Rossum  wrote:

> Maybe you didn't realize async/await don't need an event loop? Driving an
> async/await-based coroutine is just as simple as driving a yield-from-based
> one (`await` does exactly the same thing as `yield from`).
>

I realize I *can*, but it seems far from straightforward.  I guess this is
really a python-list question or something, but what is the async/await
spelling of something toy like:

In [1]: def fib():
   ...: a, b = 1, 1
   ...: while True:
   ...: yield a
   ...: a, b = b, a+b
   ...:

In [2]: from itertools import takewhile

In [3]: list(takewhile(lambda x: x<200, fib()))
Out[3]: [1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144]



> Maybe the rest of the discussion should be about deprecation vs.
> SyntaxError in Python 3.7.
>

I vote SyntaxError, of course. :-)

-- 
Keeping medicines from the bloodstreams of the sick; food
from the bellies of the hungry; books from the hands of the
uneducated; technology from the underdeveloped; and putting
advocates of freedom in prisons.  Intellectual property is
to the 21st century what the slave trade was to the 16th.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Using async/await in place of yield expression

[David Mertz]

Changing subject line because this is way off to the side.  Guido and
Nathaniel point out that you can do everything yield expressions do with
async/await *without* an explicit event loop.  While I know that is true,
it feels like the best case is adding fairly considerable ugliness to the
code in the process.


> On Sat, Nov 25, 2017 at 3:37 PM, Guido van Rossum 
> wrote:
> > Maybe you didn't realize async/await don't need an event loop? Driving an
> > async/await-based coroutine is just as simple as driving a
> yield-from-based
> > one (`await` does exactly the same thing as `yield from`).
>


> On Sun, Nov 26, 2017 at 12:29 PM, Nathaniel Smith  wrote:
> Technically anything you can write with yield/yield from could also be
> written using async/await and vice-versa, but I think it's actually
> nice to have both in the language.
>

Here is some code which is definitely "toy", but follows a pattern pretty
similar to things I really code using yield expressions:

In [1]: from itertools import takewhile
In [2]: def injectable_fib(a=1, b=2):
   ...: while True:
   ...: new = yield a
   ...: if new is not None:
   ...: a, b = new
   ...: a, b = b, a+b
   ...:
In [3]: f = injectable_fib()
In [4]: list(takewhile(lambda x: x<200, f))
Out[4]: [1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144]
In [5]: f.send((100,200))
Out[5]: 200
In [6]: list(takewhile(lambda x: x<1000, f))
Out[6]: [300, 500, 800]


Imagining that 'yield' vanished from the language tomorrow, and I wanted to
write the same thing with async/await, I think the best I can come up with
is... actually, I just don't know who to do it without any `yield`.

I can get as far as a slightly flawed:

In [9]: async def atakewhile(pred, coro):
   ...: l = []
   ...: async for x in coro:
   ...: if pred(x):
   ...: return l
   ...: l.append(x)


But I just have no idea what would go in the body of

async def afib_injectable():


(that is, if I'm prohibited a `yield` in there)

-- 
Keeping medicines from the bloodstreams of the sick; food
from the bellies of the hungry; books from the hands of the
uneducated; technology from the underdeveloped; and putting
advocates of freedom in prisons.  Intellectual property is
to the 21st century what the slave trade was to the 16th.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] What's the status of PEP 505: None-aware operators?

[David Mertz]

I like much of the thinking in Random's approach. But I still think None
isn't quite special enough to warrant it's own syntax.

However, his '(or None: name.strip()[4:].upper())' makes me realize that
what is being asked in all the '?(', '?.', '?[' syntax ideas is a kind of
ternary expression.  Except the ternary isn't based on whether a predicate
holds, but rather on whether an exception occurs (AttributeError, KeyError,
TypeError).  And the fallback in the ternary is always None rather than
being general.

I think we could generalize this to get something both more Pythonic and
more flexible.  E.g.:

val = name.strip()[4:].upper() except None

This would just be catching all errors, which is perhaps too broad.  But it
*would* allow a fallback other than None:

val = name.strip()[4:].upper() except -1

I think some syntax could be possible to only "catch" some exceptions and
let others propagate.  Maybe:

val = name.strip()[4:].upper() except (AttributeError, KeyError): -1

I don't really like throwing a colon in an expression though.  Perhaps some
other word or symbol could work instead.  How does this read:

val = name.strip()[4:].upper() except -1 in (AttributeError, KeyError)

Where the 'in' clause at the end would be optional, and default to
'Exception'.

I'll note that what this idea DOES NOT get us is:

  val = timeout ?? local_timeout ?? global_timeout

Those values that are "possibly None" don't raise exceptions, so they
wouldn't apply to this syntax.

Yours, David...


On Wed, Nov 29, 2017 at 9:03 AM, Random832  wrote:

> On Tue, Nov 28, 2017, at 15:31, Raymond Hettinger wrote:
> >
> > > I also cc python-dev to see if anybody here is strongly in favor or
> against this inclusion.
> >
> > Put me down for a strong -1.   The proposal would occasionally save a few
> > keystokes but comes at the expense of giving Python a more Perlish look
> > and a more arcane feel.
> >
> > One of the things I like about Python is that I can walk non-programmers
> > through the code and explain what it does.  The examples in PEP 505 look
> > like a step in the wrong direction.  They don't "look like Python" and
> > make me feel like I have to decrypt the code to figure-out what it does.
> >
> > timeout ?? local_timeout ?? global_timeout
> > 'foo' in (None ?? ['foo', 'bar'])
> > requested_quantity ?? default_quantity * price
> > name?.strip()[4:].upper()
> > user?.first_name.upper()
>
> Since we're looking at different syntax for the ?? operator, I have a
> suggestion for the ?. operator - and related ?[] and ?() that appeared
> in some of the proposals. How about this approach?
>
> Something like (or None: ...) as a syntax block in which any operation
> [lexically within the expression, not within e.g. called functions, so
> it's different from simply catching AttributeError etc, even if that
> could be limited to only catching when the operand is None] on None that
> is not valid for None will yield None instead.
>
> This isn't *entirely* equivalent, but offers finer control.
>
> v = name?.strip()[4:].upper() under the old proposal would be more or
> less equivalent to:
>
> v = name.strip()[4:].upper() if name is not None else None
>
> Whereas, you could get the same result with:
> (or None: name.strip()[4:].upper())
>
> Though that would technically be equivalent to these steps:
> v = name.strip if name is not None else None
> v = v() if v "
> v = v[4:] """
> v = v.upper """
> v = v() """
>
> The compiler could optimize this case since it knows none of the
> operations are valid on None. This has the advantage of being explicit
> about what scope the modified rules apply to, rather than simply
> implicitly being "to the end of the chain of dot/bracket/call operators"
>
> It could also be extended to apply, without any additional syntax, to
> binary operators (result is None if either operand is None) (or None: a
> + b), for example, could return None if either a or b is none.
>
> [I think I proposed this before with the syntax ?(...), the (or None:
> ...) is just an idea to make it look more like Python.]
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> mertz%40gnosis.cx
>



-- 
Keeping medicines from the bloodstreams of the sick; food
from the bellies of the hungry; books from the hands of the
uneducated; technology from the underdeveloped; and putting
advocates of freedom in prisons.  Intellectual property is
to the 21st century what the slave trade was to the 16th.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Is static typing still optional?

[David Mertz]

On Sun, Dec 17, 2017 at 8:22 AM, Guido van Rossum  wrote:

> On Sun, Dec 17, 2017 at 2:11 AM, Julien Salort  wrote:
>
>> Naive question from a lurker: does it mean that it works also if one
>> annotates with something that is not a type, e.g. a comment,
>>
>> @dataclass
>> class C:
>> a: "This represents the amplitude" = 0.0
>> b: "This is an offset" = 0.0
>
>
> I would personally not use the notation for this, but it is legal code.
> However static type checkers like mypy won't be happy with this.
>

Mypy definitely won't like that use of annotation, but documentation
systems might.  For example, in a hover tooltip in an IDE/editor, it's
probably more helpful to see the descriptive message than "int" or "float"
for the attribute.

What about data that isn't built-in scalars? Does this look right to people
(and will mypy be happy with it)?

@dataclass
class C:
a:numpy.ndarray = numpy.random.random((3,3))
b:MyCustomClass = MyCustomClass("foo", 37.2, 1+2j)

I don't think those look terrible, but I think this looks better:

@dataclass
class C:
a:Infer = np.random.random((3,3))
b:Infer = MyCustomClass("foo", 37.2, 1+2j)

Where the name 'Infer' (or some other spelling) was a name defined in the
`dataclasses` module.  In this case, I don't want to use `typing.Any` since
I really do want "the type of thing the default value has."

-- 
Keeping medicines from the bloodstreams of the sick; food
from the bellies of the hungry; books from the hands of the
uneducated; technology from the underdeveloped; and putting
advocates of freedom in prisons.  Intellectual property is
to the 21st century what the slave trade was to the 16th.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Is static typing still optional?

[David Mertz]

There name Data seems very intuitive to me without suggesting type
declaration as Any does (but it can still be treated as a synonym by actual
type checkers)

On Dec 22, 2017 12:12 PM, "Paul Moore"  wrote:

> On 22 December 2017 at 19:50, Gregory P. Smith  wrote:
>
> > My preference for this is "just use Any" for anyone not concerned about
> the
> > type.  But if we wanted to make it more opaque so that people need not
> > realizing that they are actually type annotations, I suggest adding an
> alias
> > for Any in the dataclasses module (dataclasses.Data = typing.Any)
> >
> > from dataclasses import dataclass, Data
> >
> > @dataclass
> > class Swallow:
> > weight_in_oz: Data = 5
> > laden: Data = False
> > species: Data = SwallowSpecies.AFRICAN
> >
> > the word "Data" is friendlier than "Any" in this context for people who
> > don't need to care about the typing module.
> >
> > We could go further and have Data not be an alias for Any if desired (so
> > that its repr wouldn't be confusing, not that anyone should be looking at
> > its repr ever).
>
> That sounds like a nice simple proposal. +1 from me.
>
> Documentation can say that variables should be annotated with "Data"
> to be recognised by the decorator, and if people are using type
> annotations an actual type can be used in place of "Data" (which acts
> the same as typing.Any. That seems to me to describe the feature in a
> suitably type-hinting-neutral way, while still making it clear how
> data classes interact with type annotations.
>
> Paul
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> mertz%40gnosis.cx
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Guido's Python 1.0.0 Announcement from 27 Jan 1994

[David Mertz]

Does anyone have an archive of the Python 1.0 documentation?  Sadly
http://www.cwi.nl/~guido/Python.html is not a live URL :-).

On Sat, Jan 27, 2018 at 9:08 AM, Chris Angelico  wrote:

> On Sun, Jan 28, 2018 at 3:58 AM, Senthil Kumaran 
> wrote:
> > Someone in HackerNews shared the Guido's Python 1.0.0 announcement from
> 27
> > Jan 1994. That is, on this day, 20 years ago.
> >
> > https://groups.google.com/forum/?hl=en#!original/comp.
> lang.misc/_QUzdEGFwCo/KIFdu0-Dv7sJ
> >
> > It is very entertaining to read.
>
> Yes, it is. In twenty years, some things have not changed at all:
>
> > Python is an interpreted language, and has the usual advantages of
> > such languages, such as run-time checks (e.g. bounds checking),
> > execution of dynamically generated code, automatic memory allocation,
> > high level operations on strings, lists and dictionaries (associative
> > arrays), and a fast edit-compile-run cycle.  Additionally, it features
> > modules, classes, exceptions, and dynamic linking of extensions
> > written in C or C++.  It has arbitrary precision integers.
>
> But some things have:
>
> > (Please don't ask me to mail it to you -- at 1.76 Megabytes it is
> > unwieldy at least...)
>
> hehe.
>
> Thanks for digging that up!
>
> ChrisA
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> mertz%40gnosis.cx
>



-- 
Keeping medicines from the bloodstreams of the sick; food
from the bellies of the hungry; books from the hands of the
uneducated; technology from the underdeveloped; and putting
advocates of freedom in prisons.  Intellectual property is
to the 21st century what the slave trade was to the 16th.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Dataclasses and correct hashability

[David Mertz]

I agree with Ethan, Elvis, and a few others. I think 'hash=True,
frozen=False' should be disabled in 3.7.  It's an attractive nuisance.
Maybe not so attractive because its obscurity, but still with no clear
reason to exist.

If many users of of dataclass find themselves defining '__hash__' with
mutable dataclass, it's perfectly possible to allow the switch combination
later. But taking it out after previously allowing it—even if every use in
the wild is actually a bug in waiting—is harder.

On Feb 2, 2018 2:10 PM, "Ethan Furman"  wrote:

> On 02/02/2018 08:09 AM, Eric V. Smith wrote:
>
>> On 2/2/2018 10:56 AM, Elvis Pranskevichus wrote:
>>
>
> My point is exactly that there is _no_ valid use case, so (hash=True,
>>> frozen=False) should not be a thing!  Why are you so insistent on adding
>>> a dangerous option which you admit is nearly useless?
>>>
>>
>> Because it's not the default, it will be documented as being an advanced
>> use case, and it's useful in rare instances.
>>
>
> Personally, I don't think advanced use-cases need to be supported by flags
> as they can be supported by just writing the __dunder__ methods.
>
> --
> ~Ethan~
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/mertz%
> 40gnosis.cx
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Dataclasses and correct hashability

[David Mertz]

Absolutely I agree. 'unsafe_hash' as a name is clear warning to users.

On Feb 4, 2018 10:43 PM, "Chris Barker"  wrote:



On Sun, Feb 4, 2018 at 11:57 PM, Gregory P. Smith  wrote:

> +1 using unsafe_hash as a name addresses my concern.
>
mine too -- anyone surprised by using this deserves what they get :-)

-CHB


On Sun, Feb 4, 2018, 9:50 PM Guido van Rossum  wrote:
>
>> Looks like this is turning into a major flamewar regardless of what I
>> say. :-(
>>
>> I really don't want to lose the ability to add a hash function to a
>> mutable dataclass by flipping a flag in the decorator. I'll explain below.
>> But I am fine if this flag has a name that clearly signals it's an unsafe
>> thing to do.
>>
>> I propose to replace the existing (as of 3.7.0b1) hash= keyword for the
>> @dataclass decorator with a simpler flag named unsafe_hash=. This would be
>> a simple bool (not a tri-state flag like the current hash=None|False|True).
>> The default would be False, and the behavior then would be to add a hash
>> function automatically only if it's safe (using the same rules as for
>> hash=None currently). With unsafe_hash=True, a hash function would always
>> be generated that takes all fields into account except those declared using
>> field(hash=False). If there's already a `def __hash__` in the function I
>> don't care what it does, maybe it should raise rather than quietly doing
>> nothing or quietly overwriting it.
>>
>> Here's my use case.
>>
>> A frozen class requires a lot of discipline, since you have to compute
>> the values of all fields before calling the constructor. A mutable class
>> allows other initialization patterns, e.g. manually setting some fields
>> after the instance has been constructed, or having a separate non-dunder
>> init() method. There may be good reasons for using these patterns, e.g. the
>> object may be part of a cycle (e.g. parent/child links in a tree). Or you
>> may just use one of these patterns because you're a pretty casual coder. Or
>> you're modeling something external.
>>
>> My point is that once you have one of those patterns in place, changing
>> your code to avoid them may be difficult. And yet your code may treat the
>> objects as essentially immutable after the initialization phase (e.g. a
>> parse tree). So if you create a dataclass and start coding like that for a
>> while, and much later you need to put one of these into a set or use it as
>> a dict key, switching to frozen=True may not be a quick option. And writing
>> a __hash__ method by hand may feel like a lot of busywork. So this is where
>> [unsafe_]hash=True would come in handy.
>>
>> I think naming the flag unsafe_hash should take away most objections,
>> since it will be clear that this is not a safe thing to do. People who
>> don't understand the danger are likely to copy a worse solution from
>> StackOverflow anyway. The docs can point to frozen=True and explain the
>> danger.
>>
>> --
>> --Guido van Rossum (python.org/~guido)
>> ___
>> Python-Dev mailing list
>> Python-Dev@python.org
>> https://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe: https://mail.python.org/mailman/options/python-dev/greg%
>> 40krypto.org
>>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/chris.
> barker%40noaa.gov
>
>


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: https://mail.python.org/mailman/options/python-dev/
mertz%40gnosis.cx
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Dataclasses and correct hashability

[David Mertz]

Honestly, the name I would most want for the keyword argument is '_hash'.
That carries the semantics I desire.

On Feb 6, 2018 10:13 AM, "Ethan Furman"  wrote:

> On 02/06/2018 09:38 AM, Guido van Rossum wrote:
>
> Where do you get the impression that one would have to explicitly request
>> __hash__ if frozen=True is set? To the
>> contrary, my proposal is for @dataclass to automatically add a __hash__
>> method when frozen=True is set. This is what the
>> code currently released as 3.7.0b1 does if hash=None (the default).
>>
>
> Which is my issue with the naming -- although, really, it's more with the
> parameter/argument:  in a hand-written class,
>
>   __hash__ = None
>
> means the object in is not hashable, but with the decorator:
>
>   @dataclass(..., hash=None, ...)
>
> it means something else.
>
> My preference for "fixing" the issue:
>
> 1) make the default be a custom object (not None), so that `hash=None`
>means disable hashing
>
> 2) change the param name -- maybe to `add_hash` (I agree with D'Aprano
>that `unsafe_hash` can be misleading)
>
> --
> ~Ethan~
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/mertz%
> 40gnosis.cx
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] The `for y in [x]` idiom in comprehensions

[David Mertz]

On Feb 23, 2018 9:26 PM, "Steven D'Aprano"  wrote:

Given a potentially expensive DRY violation like:

[(function(x), function(x)+1) for x in sequence]

there are at least five ways to solve it.


A 6th way is to wrap the expensive function in @lru_cache() to make it
non-expensive.


[(a, a+1) for x in sequence for a in [function(x)]]


It's funny to me how many people, even the BDFL, have said this is tricky
to reason about or recognize. I didn't think of it all by myself, but saw
it somewhere years ago. It seemed obvious once I saw it. Since then it's
something I do occasionally in my code without much need for thought.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] The `for y in [x]` idiom in comprehensions

[David Mertz]

FWIW, the nested loop over a single item is already in the language for 15
years or something. It's not that ugly, certainly not enough to need a new
'let' or 'where' keyword that basically does exactly the same thing with 3
fewer characters.

On Feb 23, 2018 10:04 PM, David Mertz  wrote:


On Feb 23, 2018 9:26 PM, "Steven D'Aprano"  wrote:

Given a potentially expensive DRY violation like:

[(function(x), function(x)+1) for x in sequence]

there are at least five ways to solve it.


A 6th way is to wrap the expensive function in @lru_cache() to make it
non-expensive.


[(a, a+1) for x in sequence for a in [function(x)]]


It's funny to me how many people, even the BDFL, have said this is tricky
to reason about or recognize. I didn't think of it all by myself, but saw
it somewhere years ago. It seemed obvious once I saw it. Since then it's
something I do occasionally in my code without much need for thought.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Symmetry arguments for API expansion

[David Mertz]

If anyone cares, my vote is to rip out both .as_integer_ratio() and
.is_integer() from Python. I've never used either and wouldn't want to.

Both seem like perfectly good functions for the `math` module, albeit the
former is simply the Fraction() constructor.

I can see no sane reason why anyone would ever call float.is_integer()
actually. That should always be spelled math.isclose(x, int(x)) because
IEEE-754. Attractive nuisance is probably too generous, I'd simply call the
method a bug.

On Mon, Mar 12, 2018, 2:21 PM Tim Peters  wrote:

> [Guido]
> >  as_integer_ratio() seems mostly cute (it has Tim Peters all
> > over it),
>
> Nope!  I had nothing to do with it.  I would have been -0.5 on adding
> it had I been aware at the time.
>
> - I expect the audience is tiny.
>
> - While, ya, _I_ have uses for it, I had a utility function for it
> approximately forever (it's easily built on top of math.frexp()).
>
> - Especially now, fractions.Fraction(some_float) is the same thing
> except for return type.
>
>
> > OTOH it looks like Decimal has it,
>
> Looks like ints got it first, and then spread to Decimal because "why
> not?" ;-)  The first attempt to spread it to Decimal I found was
> rejected (which would have been my vote too):
>
> https://bugs.python.org/issue8947
>
>
> > so I think this ship has sailed too and maybe it's best to add it to the
> > numeric tower just to be done with it.
>
> Or rip it out of everything.  Either way works for me ;-)
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/mertz%40gnosis.cx
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Symmetry arguments for API expansion

[David Mertz]

On Mon, Mar 12, 2018, 3:25 PM Tim Peters  wrote:

> [David Mertz ]
> > ...
> > I can see no sane reason why anyone would ever call float.is_integer()
> > actually. That should always be spelled math.isclose(x, int(x)) because
> > IEEE-754. Attractive nuisance is probably too generous, I'd simply call
> the
> > method a bug.
>
> Sometimes it's necessary to know, and especially when _implementing_
> 754-conforming functions.  For example, what negative infinity raised
> to a power needs to return depends on whether the power is an integer
> (specifically on whether it's an odd integer):
>
> >>> (-math.inf) ** 3.1
> inf
>

Weird. I take it that's what IEEE-754 says. NaN would sure be more
intuitive here since inf+inf-j is not in the domain of Reals. Well,
technically neither is inf, but at least it's the limit of the domain. :-).

>>> (-math.inf) ** 3.0 # NOTE THIS ONE
> -inf
> >>> (-math.inf) ** 2.9
> inf
>
> But, ya, for most people most of the time I agree is_integer() is an
> attractive nuisance.  People implementing math functions are famous
> for cheerfully enduring any amount of pain needed to get the job done
> ;-)
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Deprecating float.is_integer()

[David Mertz]

I've been using and teaching python for close to 20 years and I never
noticed that x.is_integer() exists until this thread. I would say the "one
obvious way" is less than obvious.

On the other hand, `x == int(x)` is genuinely obvious... and it immediately
suggests the probably better `math.isclose(x, int(x))` that is what you
usually mean.

On Wed, Mar 21, 2018, 2:08 PM Mark Dickinson  wrote:

> I'd prefer to see `float.is_integer` stay. There _are_ occasions when one
> wants to check that a floating-point number is integral, and on those
> occasions, using `x.is_integer()` is the one obvious way to do it. I don't
> think the fact that it can be misused should be grounds for deprecation.
>
> As far as real uses: I didn't find uses of `is_integer` in our code base
> here at Enthought, but I did find plenty of places where it _could_
> reasonably have been used, and where something less readable like `x % 1 ==
> 0` was being used instead. For evidence that it's generally useful: it's
> already been noted that the decimal module uses it internally. The mpmath
> package defines its own "isint" function and uses it in several places: see
> https://github.com/fredrik-johansson/mpmath/blob/2858b1000ffdd8596defb50381dcb83de2b6/mpmath/ctx_mp_python.py#L764.
> MPFR also has an mpfr_integer_p predicate:
> http://www.mpfr.org/mpfr-current/mpfr.html#index-mpfr_005finteger_005fp.
>
> A concrete use-case: suppose you wanted to implement the beta function (
> https://en.wikipedia.org/wiki/Beta_function) for real arguments in
> Python. You'll likely need special handling for the poles, which occur only
> for some negative integer arguments, so you'll need an is_integer test for
> those. For small positive integer arguments, you may well want the accuracy
> advantage that arises from computing the beta function in terms of
> factorials (giving a correctly-rounded result) instead of via the log of
> the gamma function. So again, you'll want an is_integer test to identify
> those cases. (Oddly enough, I found myself looking at this recently as a
> result of the thread about quartile definitions: there are links between
> the beta function, the beta distribution, and order statistics, and the
> (k-1/3)/(n+1/3) expression used in the recommended quartile definition
> comes from an approximation to the median of a beta distribution with
> integral parameters.)
>
> Or, you could look at the SciPy implementation of the beta function, which
> does indeed do the C equivalent of is_integer in many places:
> https://github.com/scipy/scipy/blob/11509c4a98edded6c59423ac44ca1b7f28fba1fd/scipy/special/cephes/beta.c#L67
>
> In sum: it's an occasionally useful operation; there's no other obvious,
> readable spelling of the operation that does the right thing in all cases,
> and it's _already_ in Python! In general, I'd think that deprecation of an
> existing construct should not be done lightly, and should only be done when
> there's an obvious and significant benefit to that deprecation. I don't see
> that benefit here.
>
> --
> Mark
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/mertz%40gnosis.cx
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Deprecating float.is_integer()

[David Mertz]

On Wed, Mar 21, 2018 at 3:02 PM, Tim Peters  wrote:

> [David Mertz]
> > I've been using and teaching python for close to 20 years and I never
> > noticed that x.is_integer() exists until this thread.
>
> Except it was impossible to notice across most of those years, because
> it didn't exist across most of those years ;-)
>

That's probably some of the reason.  I wasn't sure if someone used the time
machine to stick it back into Python 1.4.


> > On the other hand, `x == int(x)` is genuinely obvious..
>
> But a bad approach:  it can raise OverflowError (for infinite x); it
> can raise ValueError (for x a NaN);


These are the CORRECT answers! Infinity neither is nor is not an integer.
Returning a boolean as an answer is bad behavior; I might argue about
*which* exception is best, but False is not a good answer to
`float('inf').is_integer()`.  Infinity is neither in the Reals nor in the
Integers, but it's just as much the limit of either.

Likewise Not-a-Number isn't any less an integer than it is a real number
(approximated by a floating point number).  It's NOT a number, which is
just as much not an integer.


> and can waste relative mountains
> of time creating huge integers, e.g.,
>

True enough. But it's hard to see where that should matter.  No floating
point number on the order of 1e306 is sufficiently precise as to be an
integer in any meaningful sense.  If you are doing number theory with
integers of that size (or larger is perfectly fine too) the actual test is
`isinstance(x, int)`.  Using a float is just simply wrong for the task to
start with, whether or not those bits happen to represent something
Integral... the only case where you should see this is
"measuring/estimating something VERY big, very approximately."

For example, this can be true (even without reaching inf):

>>> x.is_integer()
True
>>> (math.sqrt(x**2)).is_integer()
False

The problem there isn't  how "is it an integer?" is spelled, it's that
> _any_ way of spelling "is it an integer?" doesn't answer the question
> they're trying to answer.  They're just plain confused about how
> floating point works.  The use of `.is_integer()` (however spelled!)
> isn't the cause of that, it's a symptom.
>

Agreed!

-- 
Keeping medicines from the bloodstreams of the sick; food
from the bellies of the hungry; books from the hands of the
uneducated; technology from the underdeveloped; and putting
advocates of freedom in prisons.  Intellectual property is
to the 21st century what the slave trade was to the 16th.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Deprecating float.is_integer()

[David Mertz]

Ok. I'm wrong on that example.

On Wed, Mar 21, 2018, 9:11 PM Tim Peters  wrote:

> [David Mertz ]
> >> For example, this can be true (even without reaching inf):
> >>
> >> >>> x.is_integer()
> >> True
> >> >>> (math.sqrt(x**2)).is_integer()
> >> False
>
> [Mark Dickinson  ]
> > If you have a moment to share it, I'd be interested to know what value of
> > `x` you used to achieve this, and what system you were on. This can't
> happen
> > under IEEE 754 arithmetic.
>
> I expect it might happen under one of the directed rounding modes
> (like "to +infinity").
>
> But under 754 binary round-nearest/even arithmetic, it's been formally
> proved that sqrt(x*x) == x exactly for all non-negative finite x such
> that x*x neither overflows nor underflows (and .as_integer() has
> nothing to do with that very strong result):
>
> https://hal.inria.fr/hal-01148409/document
>
> OTOH, the paper notes that it's not necessarily true for IEEE decimal
> arithmetic; e.g.,
>
> >>> import decimal
> >>> decimal.getcontext().prec = 4
> >>> (decimal.Decimal("31.66") ** 2).sqrt()  # result is 1 ulp smaller
> Decimal('31.65')
>
> >>> decimal.getcontext().prec = 5
> >>> (decimal.Decimal("31.660") ** 2).sqrt() # result is 1 ulp larger
> Decimal('31.661')
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Sets, Dictionaries

[David Mertz]

I agree with everything Steven says. But it's true that even as a 20-year
Python user, this is an error I make moderately often when I want an empty
set... Notwithstanding that I typed it thousands of times before sets even
existed (and still type it when I want an empty dictionary).

That said, I've sort of got in the habit of using the type initializers:

x = set()
y = dict()
z = list()

I feel like those jump out a little better visually. But I'm inconsistent
in my code.

On Thu, Mar 29, 2018, 2:03 AM Steven D'Aprano  wrote:

> Hi Julia, and welcome!
>
> On Wed, Mar 28, 2018 at 09:14:53PM -0700, Julia Kim wrote:
>
> > My suggestion is to change the syntax for creating an empty set and an
> > empty dictionary as following.
> >
> > an_empty_set = {}
> > an_empty_dictionary = {:}
> >
> > It would seem to make more sense.
>
> Indeed it would, and if sets had existed in Python since the beginning,
> that's probably exactly what we would have done. But unfortunately they
> didn't, and {} has meant an empty dict forever.
>
> The requirement to keep backwards-compatibility is a very, very hard
> barrier to cross. I think we all acknowledge that it is sad and a little
> bit confusing that {} means a dict not a set, but it isn't sad or
> confusing enough to justify breaking millions of existing scripts and
> applications.
>
> Not to mention the confusing transition period when the community would
> be using *both* standards at the same time, which could easily last ten
> years.
>
> Given that, I think we just have to accept that having to use set() for
> the empty set instead of {} is a minor wart on the language that we're
> stuck with.
>
> If you disagree, and think that you have a concrete plan that can make
> this transition work, we'll be happy to hear it, but you'll almost
> certainly need to write a PEP before it could be accepted.
>
> https://www.python.org/dev/peps/
>
>
> Thanks,
>
> --
> Steve
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/mertz%40gnosis.cx
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 572: Assignment Expressions

[David Mertz]

Strongly agree with Nick that only simple name targets should be permitted
(at least initially). NONE of the motivating cases use more complex
targets, and allowing them encourages obscurity and code golf.

On Tue, Apr 17, 2018, 8:20 AM Nick Coghlan  wrote:

> On 17 April 2018 at 17:46, Chris Angelico  wrote:
> > Syntax and semantics
> > 
> >
> > In any context where arbitrary Python expressions can be used, a **named
> > expression** can appear. This is of the form ``target := expr`` where
> > ``expr`` is any valid Python expression, and ``target`` is any valid
> > assignment target.
>
> The "assignment expressions should be restricted to names only"
> subthread from python-ideas finally crystallised for me (thanks in
> part to your own comment that 'With regular assignment (whether it's
> to a simple name or to a subscript/attribute), removing the "target
> :=" part will leave you with the same value - the value of "x := 1" is
> 1.'), and I now have a concrete argument for why I think we want to
> restrict the assignment targets to names only: all complex assignment
> targets create inherent ambiguity around the type of the expression
> result, and exactly which operations are performed as part of the
> assignment.
>
> Initially I thought the problem was specific to tuple unpacking
> syntax, but attempting to explain why subscript assignment and
> attribute assignments were OK made me realise that they're actually
> even worse off (since they can execute arbitrary code on both setting
> and retrieval, whereas tuple unpacking only iterates over iterables).
>
> Tackling those in order...
>
> Tuple unpacking:
>
> What's the result type for "a, b, c := range(3)"? Is it a range()
> object? Or is it a 3-tuple? If it's a 3-tuple, is that 3-tuple "(1, 2,
> 3)" or "(a, b, range(3))"?
> Once you have your answer, what about "a, b, c := iter(range(3))"
> or "a, b, *c := range(10)"?
>
> Whichever answers we chose would be surprising at least some of the
> time, so it seems simplest to disallow such ambiguous constructs, such
> that the only possible interpretation is as "(a, b, range(3))"
>
> Subscript assignment:
>
> What's the final value of "result" in "seq = list(); result =
> (seq[:] := range(3))"? Is it "range(3)"? Or is it "[1, 2, 3]"?
> As for tuple unpacking, does your preferred answer change for the
> case of "seq[:] := iter(range(3))"?
>
> More generally, if I write  "container[k] := value", does only
> "type(container).__setitem__" get called, or does
> "type(container).__getitem__" get called as well?
>
> Again, this seems inherently ambiguous to me, and hence best avoided
> (at least for now), such that the result is always unambiguously
> "range(3)".
>
> Attribute assignment:
>
> If I write  "obj.attr := value", does only "type(obj).__setattr__"
> get called, or does "type(obj).__getattribute__" get called as well?
>
> While I can't think of a simple obviously ambiguous example using
> builtins or the standard library, result ambiguity exists even for the
> attribute access case, since type or value coercion may occur either
> when setting the attribute, or when retrieving it, so it makes a
> difference as to whether a reference to the right hand side is passed
> through directly as the assignment expression result, or if the
> attribute is stored and then retrieved again.
>
> If all these constructs are prohibited, then a simple design principle
> serves to explain both their absence and the absence of the augmented
> assignment variants: "allowing the more complex forms of assignment as
> expressions makes the order of operations (as well as exactly which
> operations are executed) inherently ambiguous".
>
> That ambiguity generally doesn't exist with simple name bindings (I'm
> excluding execution namespaces with exotic binding behaviour from
> consideration here, as the consequences of trying to work with those
> are clearly on the folks defining and using them).
>
> > The value of such a named expression is the same as the incorporated
> > expression, with the additional side-effect that the target is assigned
> > that value::
> >
> > # Handle a matched regex
> > if (match := pattern.search(data)) is not None:
> > ...
> >
> > # A more explicit alternative to the 2-arg form of iter() invocation
> > while (value := read_next_item()) is not None:
> > ...
> >
> > # Share a subexpression between a comprehension filter clause and
> its output
> > filtered_data = [y for x in data if (y := f(x)) is not None]
>
> [snip]
>
> > Style guide recommendations
> > ===
> >
> > As this adds another way to spell some of the same effects as can
> already be
> > done, it is worth noting a few broad recommendations. These could be
> included
> > in PEP 8 and/or other style guides.
> >
> > 1. If either assignment statements or assignment expressions can be
> >used, prefer statements; they are a clear declarat

Re: [Python-Dev] PEP 572: Assignment Expressions

[David Mertz]

It's horrors like this:

g(items[idx] := idx := f())

That make me maybe +0 if the PEP only allowed simple name targets, but
decisively -1 for any assignment target in the current PEP.

I would much rather never have to read awful constructs like that than get
the minor convenience of:

if (val := some_expensive_func()) > 0:
x = call_something(val)

On Fri, Apr 20, 2018, 3:39 PM Chris Angelico  wrote:

> On Sat, Apr 21, 2018 at 2:17 AM, Christoph Groth
>  wrote:
> > Chris Barker - NOAA Federal wrote:
> >
> >> > Personally, I even slightly prefer
> >> >
> >> > a := 3
> >> >
> >> > to the commonplace
> >> >
> >> > a = 3
> >> > because it visually expresses the asymmetry of the operation.
> >>
> >> Careful here! That’s a fine argument for using := in a new language,
> >> but people using := when they don’t need an expression because they
> >> like the symbol better is a reason NOT to do this.
> >
> > Perhaps you are right and it is indeed unrealistic to expect people to
> > (eventually) shift to using := for simple assignments after 28 years of
> > Python...
>
> It's not just 28 years of Python. It's also that other languages use
> "=" for assignment. While this is by no means a clinching argument, it
> does have some weight; imagine if Python used "=" for comparison and
> ":=" for assignment - anyone who works simultaneously with multiple
> languages is going to constantly type the wrong operator. (I get this
> often enough with comment characters, but my editor will usually tell
> me straight away if I type "// blah" in Python, whereas it won't
> always tell me that I used "x = 1" when I wanted one of the other
> forms.)
>
> > One way or the other, I'd like to underline a point that I made
> > yesterday: I believe that it's important for sanity that taking any
> > existing assignment statement and replacing all occurrences of "=" by
> > ":=" does not have any effect on the program.
> >
> > PEP 572 currently proposes to make ":=" a binary operator that is
> > evaluated from right to left.
>
> This is one of the points that I was halfway through working on when I
> finally gave up on working on a reference implementation for a
> likely-doomed PEP. It might be possible to make := take an entire
> sequence of assignables and then set them left to right; however, this
> would be a lot more complicated, and I'm not even sure I want that
> behaviour. I don't want to encourage people to replace all "=" with
> ":=" just for the sake of it. The consistency is good if it can be
> achieved, but you shouldn't actually DO that sort of thing normally.
>
> Consider: one of the important reasons to define the assignment order
> is so you can reference a subscript and also use it. For instance:
>
> idx, items[idx] = new_idx, new_val
>
> But you don't need that with :=, because you can:
>
> items[idx := new_idx] = new_val
>
> (and you can use := for the second one if you wish). And actually,
> this one wouldn't even change, because it's using tuple unpacking, not
> the assignment order of chained assignments. I cannot think of any
> situation where you'd want to write this:
>
> idx = items[idx] = f()
>
> inside an expression, and thus need to write it as:
>
> g(items[idx] := idx := f())
>
> So I have no problem with a style guide saying "yeah just don't do
> that", and the PEP saying "if you do this, the semantics won't be
> absolutely identical to '='". Which it now does.
>
> Now, if someone else wants to work on the reference implementation,
> they're welcome to create this feature and then see whether they like
> it. But since I can't currently prove it's possible, I'm not going to
> specify it in the PEP.
>
> ChrisA
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/mertz%40gnosis.cx
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 572: Assignment Expressions

[David Mertz]

It feels very strange that the PEP tries to do two almost entirely
unrelated things. Assignment expressions are one thing, with merits and
demerits discussed at length.

But "fixing" comprehension scoping is pretty much completely orthogonal.
Sure, it might be a good idea. And yes there are interactions between the
behaviors. However, trying to shoehorn the one issue into a PEP on a
different topic makes all of it harder to accept.

The "broken" scoping in some slightly strange edge cases can and has been
shown in lots of examples that don't use assignment expressions. Whether or
not that should be changed needn't be linked to the real purpose of this
PEP.

On Sat, Apr 21, 2018, 10:46 AM Chris Angelico  wrote:

> On Sat, Apr 21, 2018 at 10:26 PM, Steven D'Aprano 
> wrote:
> > On Sat, Apr 21, 2018 at 05:46:44PM +1000, Chris Angelico wrote:
> >> On Sat, Apr 21, 2018 at 5:11 PM, Steven D'Aprano 
> wrote:
> >
> >> > So can you explain specifically what odd function-scope behaviour you
> >> > are referring to? Give an example please?
> >>
> >> doubled_items = [x for x in (items := get_items()) if x * 2 in items]
> >>
> >> This will leak 'items' into the surrounding scope (but not 'x').
> >
> > The "not x" part is odd, I agree, but it's a popular feature to have
> > comprehensions run in a separate scope, so that's working as designed.
> >
> > The "leak items" part is the behaviour I desire, so that's not odd, it's
> > sensible *wink*
> >
> > The reason I want items to "leak" into the surrounding scope is mostly
> > so that the initial value for it can be set with a simple assignment
> > outside the comprehension:
> >
> > items = (1, 2, 3)
> > [ ... items := items*2 ... ]
> >
> > and the least magical way to do that is to just make items an ordinary
> > local variable.
>
> You can't have your cake and eat it too. Iteration variables and names
> bound by assignment expressions are both set inside the comprehension.
> Either they both are local, or they both leak - or else we have a
> weird rule like "the outermost iterable is magical and special".
>
> >> [x for x in x if x] # This works
> >
> > The oddity is that this does work, and there's no assignment expression
> > in sight.
> >
> > Given that x is a local variable of the comprehension `for x in ...` it
> > ought to raise UnboundLocalError, as the expanded equivalent does:
> >
> >
> > def demo():
> > result = []
> > for x in x: # ought to raise UnboundLocalError
> > if x:
> > result.append(x)
> > return result
> >
> >
> > That the comprehension version runs (rather than raising) is surprising
> > but I wouldn't call it a bug. Nor would I say it was a language
> > guarantee that we have to emulate in similar expressions.
>
> See, that's the problem. That is NOT how the comprehension expands. It
> actually expands to this:
>
> def demo(it):
> result = []
> for x in it:
> if x:
> result.append(x)
> return result
> demo(iter(x))
>
> PEP 572 corrects this by making it behave the way that you, and many
> other people, expect. Current behaviour is surprising because the
> outermost iterable is special and magical.
>
> >> (x for x in 5) # TypeError
> >> (x for _ in [1] for x in 5) # Works
> >
> > Now that last one is more than just odd, it is downright bizarre. Or at
> > least it would, if it did work:
> >
> > py> list((x for _ in [1] for x in 5))
> > Traceback (most recent call last):
> >   File "", line 1, in 
> >   File "", line 1, in 
> > TypeError: 'int' object is not iterable
> >
> >
> > Are you sure about this example?
>
> Yes, I'm sure. You may notice that I didn't iterate over the genexps
> in my example. The first one will bomb out, even without iteration;
> the second one gives a valid generator object which, if iterated over
> (or even stepped once), will bomb. This is because, again, the
> outermost iterable is special and magical.
>
> > In any case, since this has no assignment expression in it, I don't see
> > why it is relevant.
>
> Because an assignment expression in the outermost iterable would, if
> the semantics are preserved, bind in the surrounding scope. It would
> be FAR more logical to have it bind in the inner scope. Consider these
> two completely different results:
>
> def f(*prefix):
> print([p + name for p in prefix for name in locals()])
> print([p + name for name in locals() for p in prefix])
>
> >>> f("* ", "$ ")
> ['* .0', '* p', '$ .0', '$ p', '$ name']
> ['* prefix', '$ prefix']
>
> The locals() as seen by the outermost iterable are f's locals, and any
> assignment expression there would be part of f's locals. The locals()
> as seen by any other iterable, by a condition, or by the primary
> expression, are the list comp's locals, and any assignment expression
> there would be part of the list comp's locals.
>
> ChrisA
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/lis

Re: [Python-Dev] PEP 572: Assignment Expressions

[David Mertz]

It could also be postponed simply by saying assignment expressions follow
the same semantics as other bindings in comprehensions... which are subject
to change pending PEP  (i.e. some different number).

On the other hand, I am one who doesn't really care about assignment
expressions in comprehensions and only see the real benefit for 'if' and
'while' statements. I'm sure if it's added, I'll wind up using them in
comprehensions, but I've been perfectly happy with this for years:

stuff = [[y, x/y] for x in range(5) for y in [f(x)]]

There's nothing quite analogous in current Python for:

while (command := input("> ")) != "quit":
print("You entered:", command)



On Sat, Apr 21, 2018, 11:57 AM Nick Coghlan  wrote:

> On 22 April 2018 at 01:44, David Mertz  wrote:
> > It feels very strange that the PEP tries to do two almost entirely
> unrelated
> > things. Assignment expressions are one thing, with merits and demerits
> > discussed at length.
> >
> > But "fixing" comprehension scoping is pretty much completely orthogonal.
> > Sure, it might be a good idea. And yes there are interactions between the
> > behaviors. However, trying to shoehorn the one issue into a PEP on a
> > different topic makes all of it harder to accept.
> >
> > The "broken" scoping in some slightly strange edge cases can and has been
> > shown in lots of examples that don't use assignment expressions. Whether
> or
> > not that should be changed needn't be linked to the real purpose of this
> > PEP.
>
> The reason it's covered in the PEP is because the PEP doesn't want to
> lock in the current "binds the name in the surrounding scope"
> semantics when assignment expressions are used in the outermost
> iterable in a comprehension.
>
> However, resolving that question *could* be postponed more simply by
> making that a SyntaxError, rather than trying to move the expression
> evaluation inside the implicitly nested scope.
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 572: Assignment Expressions

[David Mertz]

I do think the pronunciation issue that Greg notices is important.  I teach
Python for most of my living, and reading and discussing code segments is
an important part of that.  When focussing on how Python actually *spells*
something, you can't always jump to the higher-level meaning of a
construct.  For some complex expression—whether or not "binding
expressions" are added—sometimes it makes sense to give a characterization
of the *meaning* of the expression, but other times you want to say aloud
the entire spelling of the expression.

Although feelings are mixed about this, I like the "dunder" contraction for
this purpose.  It's less of a mouthful to say "dunder-init" than
"underscore-underscore-init-underscore-underscore" aloud.  And once you
learn that shorthand, it's unambiguous.

I think I'd pronounce:

if (diff := x - x_base) and (g := gcd(diff, n)) > 1:
return g

As:

"If diff bound to x minus x_base (is non-zero), and g bound to gcd of diff
comma n is greater than 1, return g"

But having a convention for pronouncing this would be nice, rather than it
being my idiosyncrasy.


On Mon, Apr 23, 2018 at 8:23 PM, Tim Peters  wrote:

> [Tim]
> >> if (diff := x - x_base) and (g := gcd(diff, n)) > 1:
> >> return g
>
> [Greg Ewing ]
> > My problem with this is -- how do you read such code out loud?
>
> In the message in which I first gave that example:
>
> if the diff isn't 0 and gcd(diff, n) > 1, return the gcd.
>That's how I _thought_ of it from the start.
>
> In my mind, `x - x_base` doesn't even exist except as a low-level
> definition of what "diff" means.  It's different for the other test:
> _there_ `g` doesn't exist except as a shorthand for "the gcd".  In one
> case it's the name that's important to me, and in the other case the
> expression.  The entire function from which this came is doing all
> arithmetic modulo `n`, so `n` isn't in my mind either - it's a
> ubiquitous part of the background in this specific function.
>
> But you did ask how_I_ would read that code ;-)  Anyone else is free
> to read it however they like.  I naturally read it in the way that
> makes most sense to me in its context.
>
>
> > From my Pascal days I'm used to reading ":=" as "becomes". So
> > this says:
> >
> >"If diff becomes x - base and g becomes gcd(diff, n) is
> > greater than or equal to 1 then return g."
> >
> > But "diff becomes x - base" is not what we're testing!
>
> I don't really follow that.  In Python,
>
> if f() and g > 1:
>
> first tests whether `f()` "is truthy", regardless of whether it does
> or doesn't appear in a binding expression.  Because this code is
> working with integers, there's an _implied_ "!= 0" comparison.
>
>
> > That makes it sound like the result of x - base may or may not
> > get assigned to diff, which is not what's happening at all.
>
> Then I suggest the problem you're having doesn't stem from the binding
> expression, but from that you're omitting to fill in the != 0 part:
> if you're not thrown by "greater than 1", I can't see how you can be
> thrown by "not zero".
>
>
> > The "as" variant makes more sense when you read it as an
> > English sentence:
> >
> >if ((x - x_base) as diff) and ...
> >
> >"If x - x_base (and by the way, I'm going to call that
> > diff so I can refer to it later) is not zero ..."
>
> So read the original as "if diff (which is x - x_base) is not zero ...".
>
> Regardless, Guido has already said "as" is DOA (Dead On Arrival)
> (illustrating that it's also common enough in English to give a short
> name before its long-winded meaning ;-) ).
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> mertz%40gnosis.cx
>



-- 
Keeping medicines from the bloodstreams of the sick; food
from the bellies of the hungry; books from the hands of the
uneducated; technology from the underdeveloped; and putting
advocates of freedom in prisons.  Intellectual property is
to the 21st century what the slave trade was to the 16th.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

[David Mertz]

>
> [Raymond Hettinger ]
> > Python is special, in part, because it is not one of those languages.
> > It has virtues that make it suitable even for elementary school children.
> > We can show well-written Python code to non-computer folks and walk
> > them through what it does without their brains melting (something I can't
> > do with many of the other languages I've used).  There is a virtue
> > in encouraging simple statements that read like English sentences
> > organized into English-like paragraphs, presenting itself like
> > "executable pseudocode".


While this is true and good for most Python code, can you honestly explain
asyncio code with async/await to these non-programmers?! What about the
interfaces between async and synchronous portions?

I've been programming for 40 years, in Python for 20 of them. I cannot read
any block of async code without thinking VERY SLOWLY about what's going on,
then getting it wrong half the time. I even teach Python almost as much as
Raymond does.

There's a certain hand-waving approach to teaching async/await where you
say not to worry about those keywords, and just assume the blocks are
coordinated "somehow, behind the scenes." That's not awful for reading
*working* code, but doesn't let you write it.

I'm not saying binding expressions are likewise reserved for a special but
important style of programming. If included, I expect them to occur
more-or-less anywhere. So Raymond's concern about teachability is more
pressing (I've only taught async twice, and I know Raymond's standard
course doesn't do it, all the other code is unaffected by that unused
'await' lurking in the syntax). Still, there are good reasons why not all
Python code is aimed at non-computer folks.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

[David Mertz]

FWIW, the combination of limiting the PEP to binding expressions and the
motivating example of sequential if/elif tests that each need to utilize an
expression in their body (e.g. matching various regexen by narrowing,
avoiding repeated indent) gets me to +1.

I still think the edge case changes to comprehension semantics is needless
for this PEP. However, it concerns a situation I don't think I've ever
encountered in the wild, and certainly never relied on the old admittedly
odd behavior.

On Thu, Apr 26, 2018, 2:01 AM Tim Peters  wrote:

> Yes, binding expressions in the current PEP support an extremely
> limited subset of what Python's assignment statements support.[...]
> Guido's if/elif/elif/elif/ ... complex text-processing example didn't,
> but because the current lack of an ability to bind-and-test in one
> gulp forced the `elif` parts to be ever-more-deeply-indented `if`
> blocks instead.
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Dealing with tone in an email

[David Mertz]

The below is really just making this whole situation worse.

On Sat, May 5, 2018 at 8:22 PM, Ivan Pozdeev via Python-Dev <
python-dev@python.org> wrote:

> As I suspected. This is a classic scenario that is occasionally seen
> anywhere: "everyone is underestimating a problem until a disaster strikes".
> The team's perception of Tkinter is basically: "well, there are slight
> issues, and the docs are lacking, but no big deal."
>
Well, this _is_ a big deal. As in, "with 15+ years of experience, 5+ with
> Python, I failed to produce a working GUI in a week; no-one on the Net,
> regardless of experience, (including Terry) is ever sure how to do things
> right; every online tutorial says: "all the industry-standard and expected
> ways are broken/barred, we have to resort to ugly workarounds to accomplish
> just about anything"" big deal. This is anything but normal, and all the
> more shocking in Python where the opposite is the norm.
>

This is simply objectively wrong, and still rather insulting to the core
developers.

The real-world fact is that many people—including the authors of IDLE,
which is included with Python itself—use Tkinter to develop friendly,
working, GUIs.  Obviously, there *is* a way to make Tkinter work.  I
confess I haven't worked with it for a while, and even when I had, it was
fairly toy apps.  I never saw any terrible problems, but I confess I also
never pushed the edges of it.

It's quite possible, even likely, that some sufficiently complicated GUI
apps are better off eschewing Tkinter and using a different GUI library.
It's also quite possible that the documentation around Tkinter could be
improved to convey more accurate messaging around this (and to convey the
common pattern of "GUI in one thread, workers in other threads."


> And now, a disaster striked. Not knowing this, I've relied on Tkinter with
> very much at stake (my income for the two following months, basically), and
> lost. If that's not a testament just how much damage Tkinter's current
> state actually does, I dunno what is.
>

I've sunk two months each into trying to wrestle quite a large number of
frameworks or libraries to do what I want.  Sometimes I finally made it
work, other times not.  That's the reality of software development.
Sometimes the problems were bugs per se, other times limits of my
understanding.  Often the problems were with extremely widely used and
"solid" libraries (not just in Python, across numerous languages).

There are a few recurring posters here and on python-ideas of whom I roll
my eyes when I see a post is from them... I think most actual core
contributors simply have them on auto-delete filters by now.  I don't know
where the threshold is exactly, but I suspect you're getting close to that
with this post.

Yours, David...


-- 
Keeping medicines from the bloodstreams of the sick; food
from the bellies of the hungry; books from the hands of the
uneducated; technology from the underdeveloped; and putting
advocates of freedom in prisons.  Intellectual property is
to the 21st century what the slave trade was to the 16th.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Slow down...

[David Mertz]

This seems like a rather bad idea. None of the core changes in the last few
versions were on the radar 10 years in advance. And likewise, no one really
knows what new issues will become critical over the next 10.

The asyncio module and the async/await keywords only developed as important
concerns for a year or two before they became part of the language.
Likewise for type annotations. Neither is used by most Python programmers,
but for a subset, they are very important.

I supposed f-strings are incidental. We could have lived without them (I
myself doughty opposed "another way to do it"). But they do make code nicer
at the cost of incompatible syntax. Likewise underscores in numbers like
17_527_103. Not everyone needs the __mmul__() operator. But for linear
algebra, 'a @ b.T' is better than 'np.dot(a, b.T)'.

On Mon, May 7, 2018, 3:10 PM Craig Rodrigues  wrote:

>
>
> On Sun, May 6, 2018 at 7:35 PM Nick Coghlan  wrote:
>
>>
>> I'm inclined to agree that a Python 3.8 PEP in the spirit of the PEP 3003
>> language moratorium could be a very good idea. Between matrix
>> multiplication, enhanced tuple unpacking, native coroutines, f-strings, and
>> type hinting for variable assignments, we've had quite a bit of syntactic
>> churn in the past few releases, and the rest of the ecosystem really hasn't
>> caught up on it all yet (and that's not just other implementations - it's
>> training material, online courses, etc, etc).
>>
>> If we're going to take such a step, now's also the time to do it, since
>> 3.8 feature development is only just getting under way, and if we did
>> decide to repeat the language moratorium, we could co-announce it with the
>> Python 3.7 release.
>>
>>
> Would it be reasonable to request a 10 year moratorium on making changes
> to the core Python language,
> and for the next 10 years only focus on things that do not require core
> language changes,
> such as improving/bugfixing existing libraries, writing new libraries,
> improving tooling, improving infrastructure (PyPI),
> improving performance, etc., etc.?
>
> There are still many companies still stuck on Python 2, so giving 10 years
> of breathing room
> for these companies to catch up to Python 3 core language, even past 2020
> would be very helpful.
>
> --
> Craig
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/mertz%40gnosis.cx
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

[David Mertz]

On Mon, Jun 25, 2018 at 5:14 PM Steve Holden  wrote:

> I'd like to ask: how many readers of ​
>
> ​this email have ever deliberately taken advantage of the limited Python 3
> scope in comprehensions and generator expressions to use what would
> otherwise be a conflicting local variable name?​
>

I have never once *deliberately* utilized the Python 3 local scoping in
comprehensions.  There were a few times in Python 2 where I made an error
of overwriting a surrounding name by using it in a comprehension, and
probably Python 3 has saved me from that a handful of times.

Where I ever made such an error, it was with names like 'x' and 'i' and
'n'.  They are useful for quick use, but "more important" variables always
get more distinctive names anyway.  Had the Python 2 behavior remained, I
would have been very little inconvenienced; and I suppose comprehensions
would have been slightly less "magic" (but less functional-programming).


>
>
> I appreciate that the scope limitation can sidestep accidental naming
> errors, which is a good thing.
>
> Unfortunately, unless we anticipate Python 4 (or whatever) also making for
> loops have an implicit scope, I am left wondering whether it's not too
> large a price to pay. After all, special cases aren't special enough to
> break the rules, and unless the language is headed towards implicit scope
> for all uses of "for" one could argue that the scope limitation is a
> special case too far. It certainly threatens to be yet another confusion
> for learners, and while that isn't the only consideration, it should be
> given due weight.
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/mertz%40gnosis.cx
>


-- 
Keeping medicines from the bloodstreams of the sick; food
from the bellies of the hungry; books from the hands of the
uneducated; technology from the underdeveloped; and putting
advocates of freedom in prisons.  Intellectual property is
to the 21st century what the slave trade was to the 16th.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python and Linux Standard Base

[David Mertz]

The main wiki page was last touched at all in 2016. The mailing list in Jan
2018 had about 8 comments, none of them actually related to LSB. They
stopped archiving the ML altogether in Feb 2018. I think it's safe to say
the parrot is dead.

On Wed, Jun 27, 2018, 9:50 AM Antoine Pitrou  wrote:

> On Wed, 27 Jun 2018 09:18:24 -0400 (EDT)
> Charalampos Stratakis  wrote:
> >
> > My question is, if there is any incentive to try and ask for
> modernization/amendment  of the standards?
> > I really doubt that any linux distro at that point can be considered lsb
> compliant at least from the
> > python side of things.
>
> One question: who maintains the LSB?
>
> The fact that the Python portion was never updated may hint that nobody
> uses it...
>
> Regards
>
> Antoine.
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/mertz%40gnosis.cx
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] What's New editing

[David Mertz]

On Sun, Jul 5, 2015 at 6:06 PM, Nick Coghlan  wrote:

> On 6 July 2015 at 03:52, R. David Murray  wrote:
> > Just so people aren't caught unawares, it is very unlikely that I will
> have
> > time to be the final editor on "What's New for 3.5" they way I was for
> 3.3 and
> > 3.4.
>
> And thank you again for your work on those!
>
> > I've tried to encourage people to keep What's New up to date, but
> > *someone* should make a final editing pass.  Ideally they'd do at least
> the
> > research Serhiy did last year on checking that there's a mention for all
> of the
> > versionadded and versionchanged 3.5's in the docs.  Even better would be
> to
> > review the NEWS and/or commit history...but *that* is a really big job
> these
> > days
>
> What would your rough estimate of the scope of work be? As you note,
> the amount of effort involved in doing a thorough job of that has
> expanded beyond what can reasonably be expected of volunteer
> contributors, so I'm wondering if it might make sense for the PSF to
> start offering a contract technical writing gig to finalise the What's
> New documentation for each new release.
>

I think I might be able to "volunteer" for the task of writing/editing the
"What's New in 3.5" docs.  I saw David's comment on it today, so obviously
haven't yet had a chance to run it by my employer (Continuum Analytics),
but I have a hunch they would allow me to do it at least in large part as
paid time.  I am experienced as a technical writer, follow python-dev,
write about new features, but am *not*, however, my self an existing core
developer.

If there is interest in this, or at least it seems plausible, I can run it
by my employer tomorrow to see about getting enough time allocated (using
David Murray's past experience as a guideline for what's likely to be
needed).

Yours, David...

-- 
Keeping medicines from the bloodstreams of the sick; food
from the bellies of the hungry; books from the hands of the
uneducated; technology from the underdeveloped; and putting
advocates of freedom in prisons.  Intellectual property is
to the 21st century what the slave trade was to the 16th.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] What's New editing

[David Mertz]

Hi Folks,

I hereby volunteer to write "What's New for Python 3.5?" if folks on
python-dev are fine with me taking the job (i.e. I ran it by Travis, my
boss at Continuum, and he's happy to allow me to do that work within my
salaried hours... so having time isn't a problem).

If this is OK with the powers-that-be, I'll coordinate with David Murray on
how best to take over this task from him.

Thanks, David...

On Sun, Jul 5, 2015 at 8:51 PM, Nick Coghlan  wrote:

> On 6 July 2015 at 12:42, David Mertz  wrote:
> > I think I might be able to "volunteer" for the task of writing/editing
> the
> > "What's New in 3.5" docs.  I saw David's comment on it today, so
> obviously
> > haven't yet had a chance to run it by my employer (Continuum Analytics),
> but
> > I have a hunch they would allow me to do it at least in large part as
> paid
> > time.  I am experienced as a technical writer, follow python-dev, write
> > about new features, but am *not*, however, my self an existing core
> > developer.
>
> I think the last point may be a positive rather than a negative when
> it comes to effectively describing new features :)
>
> > If there is interest in this, or at least it seems plausible, I can run
> it
> > by my employer tomorrow to see about getting enough time allocated (using
> > David Murray's past experience as a guideline for what's likely to be
> > needed).
>
> That would be very helpful! I'd definitely be able to find the time to
> review and merge updates, it's the research-and-writing side that
> poses a problem for me (appreciating a task is worth doing isn't the
> same thing as wanting to do it myself!).
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
>



-- 
Keeping medicines from the bloodstreams of the sick; food
from the bellies of the hungry; books from the hands of the
uneducated; technology from the underdeveloped; and putting
advocates of freedom in prisons.  Intellectual property is
to the 21st century what the slave trade was to the 16th.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] How far to go with user-friendliness

[David Mertz]

Nothing huge to add, and I'm not experienced using mock.  But the special
handling of 'assret' as a "misspelling of 'assert'" definitely strikes me
as a wart also.  That sort of thing really has no place in a library
itself, but rather only in a linter.

On Fri, Jul 17, 2015 at 9:20 AM, Steven D'Aprano 
wrote:

> On Fri, Jul 17, 2015 at 04:37:04PM +1000, Nick Coghlan wrote:
>
> > The specific typo that is checked is the only one that changes the
> > spelling without also changing the overall length and shape of the
> > word.
>
> I don't think your comment above is correct.
>
> assert => aasert aseert azzert essert assort
>
> all have the same overall length and shape.
>
> Not all spelling errors are typos (hitting the wrong key). I've seen
> spelling errors this bad, or worse, from native English writers. Poor
> spelling, bad keyboards, distraction, and dyslexia can all contribute.
> And those who aren't fluent in English will make their own spelling
> errors, and may not even notice if the length of the word changes:
>
> assert => asert
>
> For those who are dyslexic, there are spelling errors and typos that may
> be difficult to tell apart even though the shape of the word changes:
>
> assert => assery asserh
>
> (perhaps -- I'm not dyslexic, I'm just going by what I've read about
> their experience).
>
> In my opinion, this sets a bad precedent for adding special case after
> special case, and the risk is that people will feel slighted if they are
> told that their typos aren't important enough to be made a special case
> too.
>
> If Michael wishes to argue that this is a useful feature rather than an
> ugly DWIM wart, that's his perogative, but the justification that
> "assret" is the *only* such plausible typo is just plain wrong. We've
> already heard from Robert Collins that he found a bunch of silently
> failing assertions in his mocks, and none of them started with "assret".
>
>
> All-spelling-errors-are-deliberate-to-provide-new-and-exciting-ways-to-spell-old-words-ly
> y'rs,
>
> --
> Steve
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/mertz%40gnosis.cx
>



-- 
Keeping medicines from the bloodstreams of the sick; food
from the bellies of the hungry; books from the hands of the
uneducated; technology from the underdeveloped; and putting
advocates of freedom in prisons.  Intellectual property is
to the 21st century what the slave trade was to the 16th.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status on PEP-431 Timezones

[David Mertz]

At the risk of being off-topic, I realize I really DO NOT currently
understand datetime in its current incarnation.  It's too bad PEP 431
proves so difficult to implement.

Even using `pytz` is there any way currently to get sensible answers to,
e.g.:

from datetime import *
from pytz import timezone
pacific = timezone('US/Pacific')
pacific.localize(datetime(2015, 11, 1, 1, 30))  # Ambiguous time
pacific.localize(datetime(2015, 3, 8, 2, 30))   # Non-existent time


That is, what if I had *not* just looked up when the time change happens,
and was innocently trying to define one of those datetimes above?  Is there
ANY existing way to have an error raised—or check in some other way—for the
fact that one of the times occurs twice on my clock, and the other never
occurs at all?


On Sat, Jul 25, 2015 at 8:31 PM, Lennart Regebro  wrote:

> On Sun, Jul 26, 2015 at 2:56 AM, Tim Peters  wrote:
> > However, the _body_ of the PEP said nothing whatsoever about altering
> > arithmetic.  The body of the PEP sounds like it's mainly just
> > proposing to fold the pytz package into the core.  Perhaps doing
> > _just_ that much would get this project unstuck?  Hope springs eternal
> > :-)
>
> The pytz package has an API and a usage that is different from the
> datetime() module. One of the things you need to do is that after each
> time you do arithmetic, you have to normalize the result. This is done
> because the original API design did not realize the difficulties and
> complexities of timezone handling and therefore left out things like
> ambiguous times.
>
> The PEP attemps to improved the datetime modules API so that it can
> handle the ambiguous times. It also says that the implementation will
> be based on pytz, because it was my assumption that this would be
> easy, since pytz already handles ambiguous times. During my attempt of
> implementing it I realized it wasn't easy at all, and it wasn't as
> easy as folding pytz into the core.
>
> Yes, the PEP gives that impression, because that was the assumption
> when I wrote the draft. Just folding pytz into the core without
> modifying the API defeats the whole purpose of the PEP, since
> installing pytz is a trivial task.
>
> > Like what?  I'm still looking for a concrete example of what "the
> > problem" is (or even "a" problem).
>
> A problem is that you have a datetime, and add a timedelata to it, and
> it should then result in a datetime that is actually that timedelta
> later. And if you subtract the same timedelta from the result, it
> should return a datetime that is equal to the original datetime.
>
> This sounds ridiculously simple, and is ridiculously difficult to make
> happen in all cases that we want to support (Riyahd time zone and leap
> seconds not included). That IS the specific, concrete problem, and if
> you don't believe me, there is nothing I can do to convince you.
> Perhaps I am a complete moron and simply incompetent to do this, and
> in that case I'm sure you could implement this over a day, and then
> please do so, but for the love of the founders of computing I'm not
> going to spend more time repeating it on this mailing list, because
> then we would do better in having you implement this instead of
> reading emails. Me repeating this a waste of time for everyone
> involved, and I will now stop.
>
> > 
>
> I was not involved in the discussion then, and even if I had been,
> that's still before I knew anything about the topic. I don't know what
> the arguments were, and I don't think it's constructive to try to
> figure out exactly why that decision was made. That is all to similar
> to assigning blame, which only makes people feel bad. Those who get
> blamed feel bad, and those who blame feel like dicks and onlookers get
> annoyed. Let us look forward instead.
>
> I am operating both without any need to defend that decision, as I was
> not involved in it, and I am operating with 20/20 hindsight as I am
> one of the few people having tried to implement a timezone
> implementation that supports ambiguous datetimes based on that
> decision. And then it is perfectly clear and obvious that the decision
> was a mistake and that we should rectify it.
>
> The only question for me is how and when.
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/mertz%40gnosis.cx
>



-- 
Keeping medicines from the bloodstreams of the sick; food
from the bellies of the hungry; books from the hands of the
uneducated; technology from the underdeveloped; and putting
advocates of freedom in prisons.  Intellectual property is
to the 21st century what the slave trade was to the 16th.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40m

Re: [Python-Dev] PEP-498: Literal String Formatting

[David Mertz]

On Sun, Aug 9, 2015 at 11:22 AM, Eric V. Smith  wrote:
>
> I think it has to do with the nature of the programs that people write.
> I write software for internal use in a large company. In the last 13
> years there, I've written literally hundreds of individual programs,
> large and small. I just checked: literally 100% of my calls to
> %-formatting (older code) or str.format (in newer code) could be
> replaced with f-strings. And I think every such use would be an
> improvement.
>

I'm sure that pretty darn close to 100% of all the uses of %-formatting and
str.format I've written in the last 13 years COULD be replaced by the
proposed f-strings (I suppose about 16 years for me, actually).  But I
think that every single such replacement would make the programs worse.
I'm not sure if it helps to mention that I *did* actually "write the book"
on _Text Processing in Python_ :-).

The proposal just continues to seem far too magical to me.  In the training
I now do for Continuum Analytics (I'm in charge of the training program
with one other person), I specifically have a (very) little bit of the
lessons where I mention something like:

  print("{foo} is {bar}".format(**locals()))

But I give that entirely as a negative example of abusing code and
introducing fragility.  f-strings are really the same thing, only even more
error-prone and easier to get wrong.  Relying on implicit context of the
runtime state of variables that are merely in scope feels very break-y to
me still.  If I had to teach f-strings in the future, I'd teach it as a
Python wart.

That said, there *is* one small corner where I believe f-strings add
something helpful to the language.  There is no really concise way to spell:

  collections.ChainMap(locals(), globals(), __builtins__.__dict__).

If we could spell that as, say `lgb()`, that would let str.format() or
%-formatting pick up the full "what's in scope".  To my mind, that's the
only good thing about the f-string idea.

Yours, David...

-- 
Keeping medicines from the bloodstreams of the sick; food
from the bellies of the hungry; books from the hands of the
uneducated; technology from the underdeveloped; and putting
advocates of freedom in prisons.  Intellectual property is
to the 21st century what the slave trade was to the 16th.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP-498: Literal String Formatting

[David Mertz]

Y'know, I just read a few more posts over on python-ideas that I had missed
somehow.  I saw Guido's point about `**locals()` being too specialized and
magical for beginners, which I agree with.  And it's the other aspect of
"magic" that makes me not like f-strings.  The idea of *implicitly* getting
values from the local scope (or really, the global_local_builtin scope)
makes me worry about readers of code very easily missing what's really
going on within an f-string.

I don't actually care about the code injection issues and that sort of
thing.  I mean, OK I care a little bit, but my actual concern is purely
explicitness and readability.

Which brought to mind a certain thought.  While I don't like:

f'My name is {name}, my age next year is {age+1}'

I wouldn't have any similar objection to:

   'My name is {name}, my age next year is {age+1}'.scope_format()

Or

  scope_format('My name is {name}, my age next year is {age+1}')

I realize that these could be completely semantically equivalent... but the
function or method call LOOKS LIKE a runtime operation, while a one letter
prefix just doesn't look like that (especially to beginners whom I might
teach).

The name 'scope_format' is ugly, and something shorter would be nicer, but
I think this conveys my idea.

Yours, David...

On Sun, Aug 9, 2015 at 6:14 PM, David Mertz  wrote:

> On Sun, Aug 9, 2015 at 11:22 AM, Eric V. Smith  wrote:
>>
>> I think it has to do with the nature of the programs that people write.
>> I write software for internal use in a large company. In the last 13
>> years there, I've written literally hundreds of individual programs,
>> large and small. I just checked: literally 100% of my calls to
>> %-formatting (older code) or str.format (in newer code) could be
>> replaced with f-strings. And I think every such use would be an
>> improvement.
>>
>
> I'm sure that pretty darn close to 100% of all the uses of %-formatting
> and str.format I've written in the last 13 years COULD be replaced by the
> proposed f-strings (I suppose about 16 years for me, actually).  But I
> think that every single such replacement would make the programs worse.
> I'm not sure if it helps to mention that I *did* actually "write the book"
> on _Text Processing in Python_ :-).
>
> The proposal just continues to seem far too magical to me.  In the
> training I now do for Continuum Analytics (I'm in charge of the training
> program with one other person), I specifically have a (very) little bit of
> the lessons where I mention something like:
>
>   print("{foo} is {bar}".format(**locals()))
>
> But I give that entirely as a negative example of abusing code and
> introducing fragility.  f-strings are really the same thing, only even more
> error-prone and easier to get wrong.  Relying on implicit context of the
> runtime state of variables that are merely in scope feels very break-y to
> me still.  If I had to teach f-strings in the future, I'd teach it as a
> Python wart.
>
> That said, there *is* one small corner where I believe f-strings add
> something helpful to the language.  There is no really concise way to spell:
>
>   collections.ChainMap(locals(), globals(), __builtins__.__dict__).
>
> If we could spell that as, say `lgb()`, that would let str.format() or
> %-formatting pick up the full "what's in scope".  To my mind, that's the
> only good thing about the f-string idea.
>
> Yours, David...
>
> --
> Keeping medicines from the bloodstreams of the sick; food
> from the bellies of the hungry; books from the hands of the
> uneducated; technology from the underdeveloped; and putting
> advocates of freedom in prisons.  Intellectual property is
> to the 21st century what the slave trade was to the 16th.
>



-- 
Keeping medicines from the bloodstreams of the sick; food
from the bellies of the hungry; books from the hands of the
uneducated; technology from the underdeveloped; and putting
advocates of freedom in prisons.  Intellectual property is
to the 21st century what the slave trade was to the 16th.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP-498: Literal String Formatting

[David Mertz]

I know. I elided including the nonexistent `nonlocals()` in there. But it
*should* be `lngb()`.  Or call it scope(). :-)
On Aug 10, 2015 10:09 AM, "Steven D'Aprano"  wrote:

> On Sun, Aug 09, 2015 at 06:14:18PM -0700, David Mertz wrote:
>
> [...]
> > That said, there *is* one small corner where I believe f-strings add
> > something helpful to the language.  There is no really concise way to
> spell:
> >
> >   collections.ChainMap(locals(), globals(), __builtins__.__dict__).
>
> I think that to match the normal name resolution rules, nonlocals()
> needs to slip in there between locals() and globals(). I realise that
> there actually isn't a nonlocals() function (perhaps there should be?).
>
> > If we could spell that as, say `lgb()`, that would let str.format() or
> > %-formatting pick up the full "what's in scope".  To my mind, that's the
> > only good thing about the f-string idea.
>
> I like the concept, but not the name. Initialisms tend to be hard
> to remember and rarely self-explanatory. How about scope()?
>
>
> --
> Steve
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/mertz%40gnosis.cx
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] What's New editing

[David Mertz]

I have to apologize profusely here.  Just after I offered to do this (and
work even said it was OK in principle to do it on work time), my work load
went through the roof.  And now it's really already later than most of it
should have been done.  I'd still very much like to work on this, but I
wonder if maybe someone else would like to be co-author since the increased
workload doesn't actually seem likely to diminish soon.

On Wed, Sep 2, 2015 at 7:03 PM, Yury Selivanov 
wrote:

>
>
> On 2015-07-06 11:38 AM, David Mertz wrote:
>
>> Hi Folks,
>>
>> I hereby volunteer to write "What's New for Python 3.5?" if folks on
>> python-dev are fine with me taking the job (i.e. I ran it by Travis, my
>> boss at Continuum, and he's happy to allow me to do that work within my
>> salaried hours... so having time isn't a problem).
>>
>> If this is OK with the powers-that-be, I'll coordinate with David Murray
>> on how best to take over this task from him.
>>
>
> Hi David,
>
> Are you still going to work on what's new for 3.5?
>
> Yury
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/mertz%40gnosis.cx
>



-- 
Keeping medicines from the bloodstreams of the sick; food
from the bellies of the hungry; books from the hands of the
uneducated; technology from the underdeveloped; and putting
advocates of freedom in prisons.  Intellectual property is
to the 21st century what the slave trade was to the 16th.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Conversion of a standard unicode string to a bit string in Python

[David Mertz]

This list is for discussion of development of the Python core language and
standard libraries, not for development *using* Python.  It sounds like you
should probably do your homework problem on your own, actually, but if you
seek advice, something like StackOverflow or python-list are likely to be
more appropriate.

On Sat, Oct 17, 2015 at 6:22 AM, Nemo Nautilius 
wrote:

> Hi All,
> I'm currently programming a set of crypto challenges in order to get a
> deeper understanding of python and crypto. The problem is to break a
> repeating key xor data (in a file). In order to do that I need a function
> to calculate the hamming distance between two strings.  To find that one
> needs to find the differing number of *bits* in a string. Any ideas on how
> to manipulate the string at bit level?
>
> This is my first time in writing a question to the mailing list so please
> let me know anything that I need to keep in mind while asking questions.
> Thanks in advance.
>
> Gracias
> Nemo
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/mertz%40gnosis.cx
>
>


-- 
Keeping medicines from the bloodstreams of the sick; food
from the bellies of the hungry; books from the hands of the
uneducated; technology from the underdeveloped; and putting
advocates of freedom in prisons.  Intellectual property is
to the 21st century what the slave trade was to the 16th.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] type(obj) vs. obj.__class__

[David Mertz]

This recipe looks like a bad design to me to start with.  It's
too-clever-by-half, IMO.

If I were to implement RingBuffer, I wouldn't futz around with the
__class__ attribute to change it into another thing when it was full.  A
much more obvious API for users would be simply to implement a
RingBuffer.isfull() method, perhaps supported by an underlying
RingBuffer._full boolean attribute.  That's much friendlier than expecting
people to introspect the type of the thing for a question that only
occasionally matters; and when it does matter, the question is always
conceived exactly as "Is it full?" not "What class is this currently?"

So I think I'm still waiting for a compelling example where type(x) !=
x.__class__ would be worthwhile (yes, of course it's *possible*)

On Sat, Oct 17, 2015 at 10:55 PM, Steven D'Aprano 
wrote:

> On Sat, Oct 17, 2015 at 03:45:19PM -0600, Eric Snow wrote:
> > In a recent tracker issue about OrderedDict [1] we've had some
> > discussion about the use of type(od) as a replacement for
> > od.__class__.
> [...]
> > The more general question of when we use type(obj) vs. obj.__class__
> > applies to both the language and to all the stdlib as I expect
> > consistency there would result in fewer surprises.  I realize that
> > there are some places where using obj.__class__ makes more sense (e.g.
> > for some proxy support).  There are other places where using type(obj)
> > is the way to go (e.g. special method lookup).  However, the
> > difference is muddled enough that usage is inconsistent in the stdlib.
> > For example, C-implemented types use Py_TYPE() almost exclusively.
> >
> > So, would it make sense to establish some concrete guidelines about
> > when to use type(obj) vs. obj.__class__?  If so, what would those be?
> > It may also be helpful to enumerate use cases for "type(obj) is not
> > obj.__class__".
>
> I for one would like to see a definitive explanation for when they are
> different, and when you should use one or the other. The only
> obvious example I've seen is the RingBuffer from the Python Cookbook:
>
> http://code.activestate.com/recipes/68429-ring-buffer/
>
>
>
> --
> Steve
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/mertz%40gnosis.cx
>



-- 
Keeping medicines from the bloodstreams of the sick; food
from the bellies of the hungry; books from the hands of the
uneducated; technology from the underdeveloped; and putting
advocates of freedom in prisons.  Intellectual property is
to the 21st century what the slave trade was to the 16th.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] type(obj) vs. obj.__class__

[David Mertz]

I'm not sure what benchmark you used to define the speed of RingBuffer.
I'm sure you are reporting numbers accurately for your tests, but there are
"lies, damn lies, and benchmarks", so "how fast" has a lot of nuance to it.

In any case, redefining a method in a certain situation feels a lot less
magic to me than redefining .__class__, and clarity and good API are much
more important than micro-optimization for something unlikely to be on a
critical path.

That's interesting about the `self._full` variable slowing it down, I think
I'm not surprised (but obviously it depends on just how it's used).  But
one can also simply define RingBuffer.isfull() using
`self.max==len(self.data)` if you prefer that approach.  I doubt
`myringbuffer.isfull()` is something you need to call in an inner loop.

That said, I think my implementation of RingBuffer would probably look more
like (completely untested):

class RingBuffer(object):
def __init__(self, size_max):
self.data = [None] * size_max
self.size_max = size_max
self.used = 0
self.cur = 0
def append(self, val):
self.data[self.cur] = val
self.cur = (self.cur+1) % self.size_max
self.used = max(self.used, self.cur+1)
def isfull(self):
self.used == self.size_max

Feel free to try this version against whatever benchmark you have in mind.


On Sun, Oct 18, 2015 at 5:09 PM, Peter Ludemann 
wrote:

> I re-coded the "too clever by half" RingBuffer to use the same design but
> with delegation ... and it ran 50% slower. (Code available on request)
> Then I changed it to switch implementations of append() and get() when it
> got full (the code is below) and it ran at essentially the same speed as
> the original. So, there's no need to be so clever with __class__. Of
> course, this trick of replacing a method is also "too clever by half"; but
> an instance variable for "full" slows it down by 15%.
>
> class RingBuffer(object):
> def __init__(self, size_max):
> self.max = size_max
> self.data = []
> self.cur = 0
> def append(self, x):
> self.data.append(x)
> if len(self.data) == self.max:
> self.append = self.append_full
> def append_full(self, x):
> self.data[self.cur] = x
> self.cur = (self.cur + 1) % self.max
> def get(self):
> return self.data[self.cur:] + self.data[:self.cur]
>
>
>
> On 18 October 2015 at 08:45, David Mertz  wrote:
>
>> This recipe looks like a bad design to me to start with.  It's
>> too-clever-by-half, IMO.
>>
>> If I were to implement RingBuffer, I wouldn't futz around with the
>> __class__ attribute to change it into another thing when it was full.  A
>> much more obvious API for users would be simply to implement a
>> RingBuffer.isfull() method, perhaps supported by an underlying
>> RingBuffer._full boolean attribute.  That's much friendlier than expecting
>> people to introspect the type of the thing for a question that only
>> occasionally matters; and when it does matter, the question is always
>> conceived exactly as "Is it full?" not "What class is this currently?"
>>
>> So I think I'm still waiting for a compelling example where type(x) !=
>> x.__class__ would be worthwhile (yes, of course it's *possible*)
>>
>> On Sat, Oct 17, 2015 at 10:55 PM, Steven D'Aprano 
>> wrote:
>>
>>> On Sat, Oct 17, 2015 at 03:45:19PM -0600, Eric Snow wrote:
>>> > In a recent tracker issue about OrderedDict [1] we've had some
>>> > discussion about the use of type(od) as a replacement for
>>> > od.__class__.
>>> [...]
>>> > The more general question of when we use type(obj) vs. obj.__class__
>>> > applies to both the language and to all the stdlib as I expect
>>> > consistency there would result in fewer surprises.  I realize that
>>> > there are some places where using obj.__class__ makes more sense (e.g.
>>> > for some proxy support).  There are other places where using type(obj)
>>> > is the way to go (e.g. special method lookup).  However, the
>>> > difference is muddled enough that usage is inconsistent in the stdlib.
>>> > For example, C-implemented types use Py_TYPE() almost exclusively.
>>> >
>>> > So, would it make sense to establish some concrete guidelines about
>>> > when to use type(obj) vs. obj.__class__?  If so, what would those be?
>>> > It may also be helpful to enumerate use cases for "type(obj) is not
>>> > obj.__class__".
>>>
>&

Re: [Python-Dev] type(obj) vs. obj.__class__

[David Mertz]

My intuition differs from Steven's here.  But that's fine.  In any case, my
simple implementation of RingBuffer in this thread avoids either rebinding
methods or changing .__class__.

And yes, of course collections.deque is better than any of these
implementations.  I was just trying to show that any such magic is unlikely
to be necessary... and in particular that the recipe given as an example
doesn't show it is.

But still, you REALLY want your `caterpillar = Caterpillar()` to become
something of type "Butterfly" later?! Obviously I understand the biological
metaphor.  But I'd much rather have an API that provided me with
.has_metamorphosed() then have to look for the type as something new.

Btw. Take a look at Alex' talk with Anna at PyCon 2015.  They discuss
various "best practices" that have been superseded by improved language
facilities.  They don't say anything about this "mutate the __class__
trick", but I somehow suspect he'd put that in that category.

On Sun, Oct 18, 2015 at 6:47 PM, Steven D'Aprano 
wrote:

> On Sun, Oct 18, 2015 at 05:35:14PM -0700, David Mertz wrote:
>
> > In any case, redefining a method in a certain situation feels a lot less
> > magic to me than redefining .__class__
>
> That surprises me greatly. As published in the Python Cookbook[1], there
> is a one-to-one correspondence between the methods used by an object and
> its class. If you want to know what instance.spam() method does, you
> look at the class type(instance) or instance.__class__, and read the
> source code for spam.
>
> With your suggestion of re-defining the methods on the fly, you no
> longer have that simple relationship. If you want to know what
> instance.spam() method does, first you have to work out what it actually
> is, which may not be that easy. In the worst case, it might not be
> possible at all:
>
> class K:
> def method(self):
> if condition:
> self.method = random.choice([lambda self: ...,
>  lambda self: ...,
>  lambda self: ...])
>
>
> Okay, that's an extreme example, and one can write bad code using any
> technique. But even with a relatively straight-forward version:
>
> def method(self):
> if condition:
> self.method = self.other_method
>
>
> I would classify "change the methods on the fly" as self-modifying code,
> which strikes me as much more hacky and hard to maintain than something
> as simple as changing the __class__ on the fly.
>
> Changing the __class__ is just a straight-forward metamorphosis: what
> was a caterpillar, calling methods defined in the Caterpillar class, is
> now a butterfly, calling methods defined in the Butterfly class.
>
> (The only change I would make from the published recipe would be to make
> the full Ringbuffer a subclass of the regular one, so isinstance() tests
> would work as expected. But given that the recipe pre-dates the
> wide-spread use of isinstance, the author can be forgiven for not
> thinking of that.)
>
> If changing the class on the fly is a metamorphosis, then it seems to me
> that self-modifying methods are like something from The Fly, where a
> horrible teleporter accident grafts body parts and DNA from one object
> into another object... or at least *repurposes* existing methods, so
> that what was your leg is now your arm.
>
> I've done that, and found it harder to reason about than the
> alternative:
>
> "okay, the object is an RingBuffer, but is the append method the
> RingBuffer.append method or the RingBuffer.full_append method?"
>
> versus
>
> "okay, the object is a RingBuffer, therefore the append method is the
> RingBuffer.append method".
>
>
> In my opinion, the only tricky thing about the metamorphosis tactic is
> that:
>
> obj = Caterpillar()
> # later
> assert type(obj) is Caterpillar
>
> may fail. You need a runtime introspection to see what the type of obj
> actually is. But that's not exactly unusual: if you consider Caterpillar
> to be a function rather than a class constructor (a factory perhaps?),
> then it's not that surprising that you can't know what *specific*
> type a function returns until runtime. There are many functions with
> polymorphic return types.
>
>
>
>
>
> [1] The first edition of the Cookbook was edited by Python luminaries
> Alex Martelli and David Ascher, so this recipe has their stamp of
> approval. This isn't some dirty hack.
>
>
> --
> Steve
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.pyth

Re: [Python-Dev] PEP-8 wart... it recommends short names because of DOS

[David Mertz]

DOS Python programmers probably can't use `concurrent` or
`multiprocessing`. ☺
On Oct 20, 2015 6:26 PM, "Gregory P. Smith"  wrote:

> https://www.python.org/dev/peps/pep-0008/#names-to-avoid
>
> *"Since module names are mapped to file names, and some file systems are
> case insensitive and truncate long names, it is important that module names
> be chosen to be fairly short -- this won't be a problem on Unix, but it may
> be a problem when the code is transported to older Mac or Windows versions,
> or DOS."*
>
> There haven't been computers with less than 80 character file or path name
> element length limits in wide use in decades... ;)
>
> -gps
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/mertz%40gnosis.cx
>
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 8 recommends short module names because FAT is still common today (was: PEP-8 wart... it recommends short names because of DOS)

[David Mertz]

Even thumb drives use VFAT. Yes it's an ugly hack, but the names aren't
limited to 8.3.
On Oct 20, 2015 6:59 PM, "Ben Finney"  wrote:

> "Gregory P. Smith"  writes:
>
> > There haven't been computers with less than 80 character file or path
> > name element length limits in wide use in decades... ;)
>
> Not true, your computer will happily mount severely-limited filesystems.
> Indeed, I'd wager it has done so many times this year.
>
> It is *filesystems* that limit the length of filesystem entries, and the
> FAT filesystem is still in very widespread use — on devices mounted by
> the computers you use today.
>
> Yes, we have much better filesystems today, and your primary desktop
> computer will almost certainly use something better than FAT for its
> primary storage's filesystem.
>
> That does not mean Python programmers should assume your computer will
> never mount a FAT filesystem (think small flash storage), nor that a
> program you run will never need to load Python modules from that
> filesystem.
>
>
> You'd like FAT to go away forever? Great, me too. Now we need to
> convince all the vendors of every small storage device – USB thumb
> drives, network routers, all manner of single-purpose devices – to use
> modern filesystems instead.
>
> Then, maybe after another human generation has come and gone, we can
> finally expect every filesystem, in every active device that might run
> any Python code, to be using something with a reasonably-large limit for
> filesystem entries.
>
> Until then, the advice in PEP 8 to keep module names short is reasonable.
>
> --
>  \   “The most common of all follies is to believe passionately in |
>   `\the palpably not true. It is the chief occupation of mankind.” |
> _o__)—Henry L. Mencken |
> Ben Finney
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/mertz%40gnosis.cx
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 515: Underscores in Numeric Literals

[David Mertz]

Great PEP overall. We definitely don't want the restriction to grouping
numbers only in threes. South Asian crore use grouping in twos.

https://en.m.wikipedia.org/wiki/Crore
On Feb 11, 2016 7:04 PM, "Glenn Linderman"  wrote:

> On 2/11/2016 4:16 PM, Steven D'Aprano wrote:
>
> On Thu, Feb 11, 2016 at 06:03:34PM +, Brett Cannon wrote:
>
> On Thu, 11 Feb 2016 at 02:13 Steven D'Aprano  
>  wrote:
>
>
> On Wed, Feb 10, 2016 at 08:41:27PM -0800, Andrew Barnert wrote:
>
>
> And honestly, are you really claiming that in your opinion, "123_456_"
> is worse than all of their other examples, like "1_23__4"?
>
>
> Yes I am, because 123_456_ looks like you've forgotten to finish typing
> the last group of digits, while 1_23__4 merely looks like you have no
> taste.
>
>
>
> OK, but the keyword in your sentence is "taste".
>
>
> I disagree. The key *idea* in my sentence is that the trailing
> underscore looks like a programming error. In my opinion, avoiding that
> impression is important enough to make trailing underscores a syntax
> error.
>
> I've seen a few people vote +1 for things like 123_j and 1.23_e99, but I
> haven't seen anyone in favour of trailing underscores. Does anyone think
> there is a good case for allowing trailing underscores?
>
>
>
> If we update PEP 8 for our
> needs to say "Numerical literals should not have multiple underscores in a
> row or have a trailing underscore" then this is taken care of. We get a
> dead-simple rule for when underscores can be used, the implementation is
> simple, and we get to have more tasteful usage in the stdlib w/o forcing
> our tastes upon everyone or complicating the rules or implementation.
>
>
> I think this is a misrepresentation of the alternative. As I see it, we
> have two alternatives:
>
> - one or more underscores can appear AFTER the base specifier or any digit;
> - one or more underscores can appear BETWEEN two digits.
>
> To describe the second alternative as "complicating the rules" is, I
> think, grossly unfair. And if Serhiy's proposal is correct, the
> implementation is also no more complicated:
>
> # underscores after digits
> octinteger: "0" ("o" | "O") "_"* octdigit (octdigit | "_")*
> hexinteger: "0" ("x" | "X") "_"* hexdigit (hexdigit | "_")*
> bininteger: "0" ("b" | "B") "_"* bindigit (bindigit | "_")*
>
>
> # underscores after digits
> octinteger: "0" ("o" | "O") (octdigit | "_")*
> hexinteger: "0" ("x" | "X") (hexdigit | "_")*
> bininteger: "0" ("b" | "B") (bindigit | "_")*
>
>
> An extra side effect is that there are more ways to write zero.  0x, 0b,
> 0o, 0X, 0B, 0O, 0x_, 0b_, 0o_, etc.
> But most people write   0   anyway, so those would be bad style, anyway,
> but it makes the implementation simpler.
>
>
>
> # underscores between digits
> octinteger: "0" ("o" | "O") octdigit (["_"] octdigit)*
> hexinteger: "0" ("x" | "X") hexdigit (["_"] hexdigit)*
> bininteger: "0" ("b" | "B") bindigit (["_"] bindigit)*
>
>
> The idea that the second alternative "forc[es] our tastes on everyone"
> while the first does not is bogus. The first alternative also prohibits
> things which are a matter of taste:
>
> # prohibited in both alternatives
> 0_xDEADBEEF
> 0._1234
> 1.2e_99
> -_1
> 1j_
>
>
> I think that there is broad agreement that:
>
> - the basic idea is sound
> - leading underscores followed by digits are currently legal
>   identifiers and this will not change
> - underscores should not follow the sign - +
> - underscores should not follow the decimal point .
> - underscores should not follow the exponent e|E
> - underscores will not be permitted inside the exponent (even if
>   it is harmless, it's silly to write 1.2e9_9)
> - underscores should not follow the complex suffix j
>
> and only minor disagreement about:
>
> - whether or not underscores will be allowed after the base
>   specifier 0x 0o 0b
>
>
> +1 to allow underscores after the base specifier.
>
> - whether or not underscores will be allowed before the decimal
>   point, exponent and complex suffix.
>
>
> +1 to allow them. There may be cases where they are useful, and if it is
> not useful, it would not be used.  I really liked someone's style guide
> proposal: use of underscore within numeric constants should only be done to
> aid readability.  However, pre-judging what aids readability to one
> person's particular taste is inappropriate.
>
> Can we have a show of hands, in favour or against the above two? And
> then perhaps Guido can rule on this one way or the other and we can get
> back to arguing about more important matters? :-)
>
> In case it isn't obvious, I prefer to say No to allowing underscores
> after the base specifier, or before the decimal point, exponent and
> complex suffix.
>
> I think it was obvious :)  And I think we disagree. And yes, there are
> more important matters. But it was just a couple days ago when I wrote a
> big constant in some new code that I was thinking how nice it would be if I
> could put a delimiter in there... so I'll be glad for the feat

Re: [Python-Dev] Examples for PEP 572

[David Mertz]

On Wed, Jul 4, 2018 at 3:02 AM Chris Angelico  wrote:

> "Assignment is a statement" -- that's exactly the point under discussion.
> "del is a statement" -- yes, granted
> "function and class declarations are statements" -- class, yes, but
> you have "def" and "lambda" as statement and expression equivalents.
> "import is a statement" -- but importlib.import_module exists for a reason

I'm going to assume that your term "mutating" there was simply a
> miswording, and that you're actually talking about *name binding*,
> which hitherto occurs only in statements. Yes, this is true.
>

Nope, not actually:

>>> del foo
>>> print(globals().update({'foo':42}), foo)
None 42


-- 
Keeping medicines from the bloodstreams of the sick; food
from the bellies of the hungry; books from the hands of the
uneducated; technology from the underdeveloped; and putting
advocates of freedom in prisons.  Intellectual property is
to the 21st century what the slave trade was to the 16th.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Examples for PEP 572

[David Mertz]

Hmmm... I admit I didn't expect quite this behavior. I'm don't actually
understand why it's doing what it does.

>>> def myfun():
...print(globals().update({'foo', 43}), foo)
...
>>> myfun()
Traceback (most recent call last):
  File "", line 1, in 
  File "", line 2, in myfun
TypeError: cannot convert dictionary update sequence element #0 to a
sequence

That said, this is a silly game either way.  And even though you CAN
(sometimes) bind in an expression pre-572, that's one of those perverse
corners that one shouldn't actually use.

On Wed, Jul 4, 2018 at 9:58 AM Chris Angelico  wrote:

> On Wed, Jul 4, 2018 at 11:52 PM, David Mertz  wrote:
> > On Wed, Jul 4, 2018 at 3:02 AM Chris Angelico  wrote:
> >>
> >> "Assignment is a statement" -- that's exactly the point under
> discussion.
> >> "del is a statement" -- yes, granted
> >> "function and class declarations are statements" -- class, yes, but
> >> you have "def" and "lambda" as statement and expression equivalents.
> >> "import is a statement" -- but importlib.import_module exists for a
> reason
> >>
> >> I'm going to assume that your term "mutating" there was simply a
> >> miswording, and that you're actually talking about *name binding*,
> >> which hitherto occurs only in statements. Yes, this is true.
> >
> >
> > Nope, not actually:
> >
> >>>> del foo
> >>>> print(globals().update({'foo':42}), foo)
> > None 42
> >
>
> Try it inside a function though.
>
> ChrisA
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/mertz%40gnosis.cx
>


-- 
Keeping medicines from the bloodstreams of the sick; food
from the bellies of the hungry; books from the hands of the
uneducated; technology from the underdeveloped; and putting
advocates of freedom in prisons.  Intellectual property is
to the 21st century what the slave trade was to the 16th.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Examples for PEP 572

[David Mertz]

On Wed, Jul 4, 2018 at 12:13 PM Steven D'Aprano  wrote:

> On Wed, Jul 04, 2018 at 10:20:35AM -0400, David Mertz wrote:
> > Hmmm... I admit I didn't expect quite this behavior. I'm don't actually
> > understand why it's doing what it does.
> >
> > >>> def myfun():
> > ...print(globals().update({'foo', 43}), foo)
>
> Try it with a dict {'foo': 43} instead of a set :-)



> I think Chris meant to try it inside a function using locals() rather
> than globals.


Ah... you say "tomato" I say "raspberry"... set, dict...

Yeah, typo fixed, it makes more sense.  Still, even a `globals().update()`
expression is a binding operation.  But it works perfectly fine with
locals() also :-):

>>> def myfun():
...print(locals().update({'foo': 44}), locals().get('foo'))
...
>>> myfun()
None 44

-- 
Keeping medicines from the bloodstreams of the sick; food
from the bellies of the hungry; books from the hands of the
uneducated; technology from the underdeveloped; and putting
advocates of freedom in prisons.  Intellectual property is
to the 21st century what the slave trade was to the 16th.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 572: Do we really need a ":" in ":="?

[David Mertz]

On Thu, Jul 5, 2018, 7:46 PM Alexander Belopolsky <
alexander.belopol...@gmail.com> wrote:

>  It also appears that there are no cases where = can be substituted for :=
> and not cause a syntax error.  This means that ":" in ":=" is strictly
> redundant.
>

Under your proposal, this is ambiguous: 'myfun(foo=5, bar=7)'
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Call for prudence about PEP-572

[David Mertz]

The case I find more reasonable is assignment in earlier arguments:

z = something ()
w = myfun(x := get_data(), y=calculate(x, z))

I would probably recommend against that in code review, but it's not
absurdly obfuscated.

On Sun, Jul 8, 2018, 1:15 PM Giampaolo Rodola'  wrote:

>
>
> On Sun, Jul 8, 2018 at 6:45 PM Steve Holden  wrote:
>
>> On Sun, Jul 8, 2018 at 10:41 AM, Giampaolo Rodola' 
>> wrote:
>>
>>> ​[...]
>>> I find that (space between the parentheses of a function call
>>> statement) too unnatural as a place where to put an assignment. It is
>>> not even "guarded" by a keyword like "if" or  "while" which can help as
>>> indicators that an assignment may occur. Also, I think it's way too easy to
>>> confuse it with a keyword argument:
>>>
>>> >>> foo(x = 1)  # keyword arg
>>> >>> foo(x := 1)  # assignment + value passing
>>> ​[...]
>>>
>>
>> ​But the PEP 8 spellings are​
>>
>> foo(x=1)
>>
>> and
>>
>>f(x := 1).
>>
>> The extra spacing makes it obvious that this isn't a regular named
>> argument.
>>
>
> What if the author of the code I'm reading didn't respect PEP-8? I don't
> think it's fair to invoke PEP-8 as a counter-measure to obviate a syntax
> which can clearly be mistaken with something else simply by omitting 2
> spaces. Not to mention that I don't see why anyone would want to declare a
> variable in there in the first place.
>
> --
> Giampaolo - http://grodola.blogspot.com
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/mertz%40gnosis.cx
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 572: Do we really need a ":" in ":="?

[David Mertz]

On Thu, Jul 12, 2018, 1:24 PM Barry Warsaw  wrote:

> It’s not the first time I’ve found myself in this position with a new
> Python feature, and it’s one of the reasons I deeply trust Guido’s
> intuition and sensibilities.
>

Sure... Except for the terrible choice to drop the '<>' inequality
operator, and why all my scripts start with barry_as_FLUFL. :-)

>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Naming comprehension syntax [was Re: Informal educator feedback on PEP 572 ...]

[David Mertz]

I've pretty much always taught using the "comprehension" term. It makes
sense to introduce comprehensions on concrete collections first. Then I
typically say something like "This special kind of comprehension is called
a 'generator expression'". Usually that's accompanied by a motivation like
creating a listcomp of a hundred million items, then showing that creating
the generator expression is instantaneous.

However, after the initial introduction, I consistently call it a generator
expression. Albeit, for the students I teach—data scientists and quants,
mostly—there's not a lot of time spent on that being the introduction (by
then I'm talking about NumPy and Pandas, and scikit-learn, and Seaborn, abd
Statsmodels, and so on. If things are "lazy" it's because they are Dask
deferred or Dask DataFrame.

On Sun, Jul 15, 2018, 1:02 PM Chris Barker via Python-Dev <
python-dev@python.org> wrote:

> Thanks Nick,
>
> I'll adopt this approach when I update my teaching materials.
>
> If I think of it, I"ll post here when I do that
>
> -CHB
>
>
> On Sun, Jul 15, 2018 at 12:21 AM, Nick Coghlan  wrote:
>
>> On 13 July 2018 at 15:30, Chris Barker via Python-Dev
>>  wrote:
>> > On Mon, Jul 9, 2018 at 3:18 PM, Guido van Rossum 
>> wrote:
>> >>
>> >> Definitely docs first. And we should keep references to generator
>> >> expressions too, if only to explain that they've been renamed.
>> >>
>> >> Perhaps someone should try it out in a 3rd party tutorial to see how it
>> >> goes?
>> >
>> >
>> > I'm not sure what "trying it out in a tutorial" would look like.
>> >
>> > I try to be pretty clear about terminology when I teach newbies -- so I
>> > don't want to tell anyone this new thing is called a "generator
>> > comprehension" if they aren't going to see that term anywhere else.
>>
>> Nina Zakharenko made the "they're officially called generator
>> expressions, but I find it more helpful to think of them as generator
>> comprehensions" observation in her PyCon 2018 presentation on "Elegant
>> Solutions for Everyday Python Problems":
>>
>> https://www.slideshare.net/nnja/elegant-solutions-for-everyday-python-problems-pycon-2018/27
>>
>> The article from Ned Batchelder mentioned in that slide is this one,
>> which goes through the history of Raymond originally proposing the
>> notion as generator comprehensions, them getting changed to generator
>> expressions during the PEP 289 discussions, and then asking if it
>> might be worth going back to the originally suggested name:
>> https://nedbatchelder.com/blog/201605/generator_comprehensions.html
>>
>> And then in PEP 572, it was found that being able to group all 4
>> constructs (list/set/dict comps + generator expressions) under a
>> single term was a genuinely useful shorthand:
>> https://www.python.org/dev/peps/pep-0572/#scope-of-the-target
>>
>> So trying out the terminology in a tutorial context would be to do
>> something similar to what Nina did in her talk: introduce the notion
>> of list/set/dict/generator comprehensions, and then make a side note
>> that the latter are officially referred to as "generator expressions".
>>
>> This wouldn't be the first time that terminology has differed between
>> Python-as-commonly-taught and Python-as-formally-defined, as I've yet
>> to hear anyone refer to container displays outside a language design
>> discussion - everyone else calls them container literals (or, more
>> typically, a literal for the specific builtin container type being
>> discussed).
>>
>> In this case, though, we'd be considering eventually changing the
>> language reference as well, and perhaps even some day the AST node
>> name (from GeneratorExp to GeneratorComp).
>>
>> We wouldn't need to change anything in the grammar definition (since
>> that already shares the comp_for and comp_if syntax definitions
>> between container comprehensions and generator expressions), or the
>> AST node structure (since GeneratorExp already uses a "comprehensions"
>> attribute, the same as the ListComp/SetComp/DictComp nodes).
>>
>> Cheers,
>> Nick.
>>
>> --
>> Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
>>
>
>
>
> --
>
> Christopher Barker, Ph.D.
> Oceanographer
>
> Emergency Response Division
> NOAA/NOS/OR&R(206) 526-6959   voice
> 7600 Sand Point Way NE   (206) 526-6329   fax
> Seattle, WA  98115   (206) 526-6317   main reception
>
> chris.bar...@noaa.gov
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/mertz%40gnosis.cx
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Inclusion of lz4 bindings in stdlib?

[David Mertz]

+1 to Brett's idea. It's hard to have a good mental model already of which
compression algorithms are and are not in stdlib. A package to contain them
all would help a lot.

On Wed, Nov 28, 2018, 12:56 PM Brett Cannon  Are we getting to the point that we want a compresslib like hashlib if we
> are going to be adding more compression algorithms?
>
> On Wed, 28 Nov 2018 at 08:44, Antoine Pitrou  wrote:
>
>> On Wed, 28 Nov 2018 10:28:19 +
>> Jonathan Underwood  wrote:
>> > Hi,
>> >
>> > I have for sometime maintained the Python bindings to the LZ4
>> > compression library[0, 1]:
>> >
>> > I am wondering if there is interest in having these bindings move to
>> > the standard library to sit alongside the gzip, lzma etc bindings?
>> > Obviously the code would need to be modified to fit the coding
>> > guidelines etc.
>>
>> Personally I would find it useful indeed.  LZ4 is very attractive
>> when (de)compression speed is a primary factor, for example when
>> sending data over a fast network link or a fast local SSD.
>>
>> Another compressor worth including is Zstandard (by the same author as
>> LZ4). Actually, Zstandard and LZ4 cover most of the (speed /
>> compression ratio) range quite well. Informative graphs below:
>>
>> https://gregoryszorc.com/blog/2017/03/07/better-compression-with-zstandard/
>>
>> Regards
>>
>> Antoine.
>>
>>
>> ___
>> Python-Dev mailing list
>> Python-Dev@python.org
>> https://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe:
>> https://mail.python.org/mailman/options/python-dev/brett%40python.org
>>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/mertz%40gnosis.cx
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Inclusion of lz4 bindings in stdlib?

[David Mertz]

On Thu, Nov 29, 2018, 2:55 PM Paul Moore  ... and some users need a single, unambiguous choice for the
> "official, complete" distribution. Which need the current stdlib
> serves extremely well.
>

Except it doesn't. At least not for a large swatch of users.

10 years ago, what I wanted in Python was pretty much entirely in the
stdlib. The contents of stdlib haven't changed that much since then, but MY
needs have.

For what I do personally, a distribution without NumPy, Pandas, Numba,
scikit-learn, and matplotlib is unusably incomplete. On the other hand, I
rarely care about Django, Twisted, Whoosh, or Sphinx. But some users need
those things, and even lots of supporting packages in their ecosystems.

What makes a "complete distribution?" It really depends on context. The
stdlib is an extremely good compromise, but it absolutely is a compromise.
I feel like there is plenty of room for different purpose-driven supersets
of the stdlib to make different compromises. Steve Dower lists 10 or so
such distros; what they have in common is that SOMEONE, decided to curate a
collection... which does not need any approval from the PSF or the core
developers.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Interested in serving on Steering Council

[David Mertz]

Hi Core Developers,

First thing: I am *not* a CPython committer.  I think most of you who are
will be somewhat familiar with me though.

Second: I was a Director of the PSF for a long while, and continue to chair
some Working Groups.  I've been mentioned in some PEPs.  I have written a
lot of articles and have given a lot of talks about Python, including about
recent or pending PEPs and similar matters.  I continue to work and train
around Python and open source (now with a focus on "data science", whatever
that is).

Third: I follow python-ideas and python-dev rather closely, and fairly
often contribute ideas to those lists.

Fourth: As I read PEP 8016, I cannot nominate myself to the Steering
Committee.  That seems good and proper to me.  But I believe I would be a
relevant and helpful member of the future Steering Committee if someone
wishes to nominate me and if the voters wish to elect me.

Thanks, David Mertz...

-- 
Keeping medicines from the bloodstreams of the sick; food
from the bellies of the hungry; books from the hands of the
uneducated; technology from the underdeveloped; and putting
advocates of freedom in prisons.  Intellectual property is
to the 21st century what the slave trade was to the 16th.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Interested in serving on Steering Council

[David Mertz]

I do not wish to presume too much on the judgement of the core developers.
But I thank Steve Dower for his characterizations which pretty much exactly
explain why I've had those involvements with the Python community and
language I have had, and haven't done other things.

I've been part of the Python community since 1998, but really active in it
since about 2001.  During the early 2000s, I wrote a large number of widely
read articles promoting Python, often delving into explaining semi-obscure
features and language design issues.  Most of these were with in my column
_Charming Python_.  I believe that several changes in Python itself—such as
making coroutines easier to use and the design of metaclasses and class
decorators—were significantly influenced by things I wrote on the topics.

Mostly in the period after writing that column, i.e. during the 2010s, I
served as a Director of the PSF; both before and since my time as a
Director, I've chaired several PSF committees.  That likewise felt like a
way I could advance Python best, but from more of an organizational or
social perspective than a technical one.  It is interesting to me that
whereas when I started volunteering for the PSF, there was significant
overlap between the PSF board and the core-committers, I think there is
little or no overlap today.  For better or worse, PSF is much more
community than technical today.  I feel like my own skills and interest
remain somewhat at the intersection of those aspects of Python.

I did not choose during that time, nor since, to become a CPython core
developer.  I've certainly contributed to other projects in the Python
ecosystem (I'm not sure if those are "related projects" in the sense Steve
mentions).  Part of that is time commitment needed, but more of it is my
personal strategic choices about what I could best do to advance Python in
the world.  I've felt I can do more by writing, speaking, and participating
in the PSF, than I would have by working on the CPython code base itself.

In particular, I always felt that I am not nearly as strong of a *C*
developer as are most core developers.  In Python itself, yes, but not in
C.  I am certain that I could have found some small bug to fix or small
feature to add, and gotten it accepted.  But doing that would have taken me
comparatively more effort than it would many others; I felt that effort was
better targeted towards educating Python users and teaching the user-level
language design choices Python has made.

If the core developers feel that the overwhelming qualification for the
Steering Committee is familiarity with the C code base of CPython, then
indeed I am not the best candidate for that.  If language design issues are
more important—and especially if thinking about Python's place among users
and industry are important, then I think I'm a very good candidate for the
role.  In particular, I believe my judgement about "Is this feature good
for Python users?" would be as good as that of most anyone (maybe other
than Guido); but I recognize that my judgement about "Is this feature
straightforward to implement in CPython?" or "What are the performance
implications of this features?" are weaker than those of most core
developers.  Not to say I have *no* instinct about those other questions,
but I know to defer.

Best, David...


> (*) (or Committee, I don't remember :-)
> David may of course provide an answer for himself, but allow me to
> provide my answer (and this is why I pushed for allowing external
> nominations).
>
> Historically, the only reason to become a core committer was to commit
> code. Some of us no doubt desired or demonstrated greater influence, but
> all of us have committed code or reviewed and merged PRs, either
> directly to CPython or one of the related projects.
>
> This is not a job for everyone, but it's been the only job we had on offer.
>
> The closest alternative job was to be elected to the board of the Python
> Software Foundation. But this is still not a job for everyone. They also
> are not considered core committers, despite making significant
> contributions.
>
> We now have a new job on offer. Exactly what that job involves isn't
> quite defined yet, but it will certainly include some amount of
> project/program/process management, likely some customer/user engagement
> (or relationship management, if you prefer), and potentially some
> independent decision making.
>
> Guido is the only core developer who has previously contributed to
> Python in this way (whatever "this way" turns out to mean). The rest of
> us happily worked under "someone else" doing it.
>
> Meanwhile, many non-core committers in the Python community have spent
> their time building companies, consulting businesses or educational
> courses. Spending time writing code and reviewing PRs is not how they
> want to contribute, and so they have contributed in other ways -
> including writing and often reviewing PEPs. There was no need for them
> to be a core 

Re: [Python-Dev] ctypes: is it intentional that id() is the only way to get the address of an object?

[David Mertz]

On Fri, Jan 18, 2019, 5:55 AM Antoine Pitrou 
> > id() returning the address of the object should be a guaranteed feature
>
> For me, the definitive answer is "yes, it's a CPython feature".
> That doesn't mean the CPython feature has to live forever.  We may want
> to deprecate it at some point


Whenever I've taught Python (quite a bit between writing, in person, and
webinars), I have been very explicit in stating that id(obj) returns some
unique number for each object, and mentioned that for MANY Python objects
CPython users an implementation convenience of using the memory address.

Every time I've explained it I've said not to rely on that implementation
detail. It's not true for small integers, for example, even in CPython.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] ctypes: is it intentional that id() is the only way to get the address of an object?

[David Mertz]

Oh, bracket my brain glitch on small integers.  Yes, they still give id()
of memory address, they just get reused, which is different.  Nonetheless,
I never teach id(obj)
== ctypes.c_void_p.from_buffer(ctypes.py_object(b)).value ... and not only
because I only learned the latter spelling from eryk sun.

On Fri, Jan 18, 2019 at 10:29 AM David Mertz  wrote:

> On Fri, Jan 18, 2019, 5:55 AM Antoine Pitrou 
>>
>> > id() returning the address of the object should be a guaranteed feature
>>
>> For me, the definitive answer is "yes, it's a CPython feature".
>> That doesn't mean the CPython feature has to live forever.  We may want
>> to deprecate it at some point
>
>
> Whenever I've taught Python (quite a bit between writing, in person, and
> webinars), I have been very explicit in stating that id(obj) returns some
> unique number for each object, and mentioned that for MANY Python objects
> CPython users an implementation convenience of using the memory address.
>
> Every time I've explained it I've said not to rely on that implementation
> detail. It's not true for small integers, for example, even in CPython.
>


-- 
Keeping medicines from the bloodstreams of the sick; food
from the bellies of the hungry; books from the hands of the
uneducated; technology from the underdeveloped; and putting
advocates of freedom in prisons.  Intellectual property is
to the 21st century what the slave trade was to the 16th.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] How to update namedtuple asdict() to use dict instead of OrderedDict

[David Mertz]

Ditto +1 option 4

On Wed, Jan 30, 2019, 5:56 PM Paul Moore  On Wed, 30 Jan 2019 at 22:35, Raymond Hettinger
>  wrote:
> > My recommendation is Option 4 as being less disruptive and more
> beneficial than the other options.  In the unlikely event that anyone is
> currently depending on the reordering methods for the output of _asdict(),
> the remediation is trivially simple:   nt._asdict() ->
> OrderedDict(nt.as_dict()).
> >
> > What do you all think?
>
> +1 from me on option 4.
>
> Paul
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/mertz%40gnosis.cx
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Register-based VM [Was: Possible performance regression]

[David Mertz]

Parrot got rather further along than rattlesnake as a register based VM. I
don't think it every really beat CPython in speed though.

http://parrot.org/

On Mon, Mar 11, 2019, 5:57 PM Neil Schemenauer 
wrote:

> On 2019-02-27, Victor Stinner wrote:
> > The compiler begins with using static single assignment form (SSA) but
> > then uses a register allocator to reduce the number of used registers.
> > Usually, at the end you have less than 5 registers for a whole
> > function.
>
> In case anyone is interested on working on this, I dug up some
> discussion from years ago.  Advice from Tim Peters:
>
> [Python-Dev] Rattlesnake progress
> https://mail.python.org/pipermail/python-dev/2002-February/020172.html
> https://mail.python.org/pipermail/python-dev/2002-February/020182.html
> https://mail.python.org/pipermail/python-dev/2002-February/020146.html
>
> Doing a prototype register-based compiler in Python seems like a
> good idea.  Using the 'compiler' package would give you a good
> start.  I think this is the most recent version of that package:
>
> https://github.com/pfalcon/python-compiler
>
> Based on a little poking around, I think it has not been updated for
> the 16-bit word code.  Shouldn't be too hard to make it work though.
>
> I was thinking about the code format on the weekend.  Using
> three-register opcodes seems a good idea.   We could could retain
> the 16-bit word code format.  For opcodes that use three registers,
> use a second word for the last two registers.  I.e.
>
> <8 bit opcode><8 bit register #>
> <8 bit register #><8 bit register #>
>
> Limit the number of registers to 256.  If you run out, just push and
> pop from stack.  You want to keep the instruction decode path in the
> evaluation loop simple and not confuse the CPU branch predictor.
>
> Regards,
>
>   Neil
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/mertz%40gnosis.cx
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Is XML serialization output guaranteed to be bytewise identical forever?

[David Mertz]

In my opinion, any test that relied on a non-promised accident of
serialization is broken today. Very often, such bad tests mask bad
production code that makes the same unsafe assumptions.

This is similar to tests that assumed a certain dictionary order, before we
got guaranteed insertion order. Or like tests that rely on object identity
of short strings or small ints. Or like non-guaranteed identities in
pickles across versions.

In a way, this case makes bugs worse because they are not only a Python
internal matter. XML is used to communicate among many tools and
programming languages, and relying on assumptions those other tools will
not follow us a bad habit. Sure, most tests probably don't get to the point
of touching those external tools themselves, but staying from bad
assumptions about the domain isn't best practices.

That said, I think aN XML canonicalization function is generally a good
thing for Python to have. But it shouldn't be a stopper in releases.

On Mon, Mar 18, 2019, 6:47 PM Raymond Hettinger 
wrote:

> We're having a super interesting discussion on
> https://bugs.python.org/issue34160 .  It is now marked as a release
> blocker and warrants a broader discussion.
>
> Our problem is that at least two distinct and important users have written
> tests that depend on exact byte-by-byte comparisons of the final
> serialization.  So any changes to the XML modules will break those tests
> (not the applications themselves, just the test cases that assume the
> output will be forever, byte-by-byte identical).
>
> In theory, the tests are incorrectly designed and should not treat the
> module output as a canonical normal form.  In practice, doing an equality
> test on the output is the simplest, most obvious approach, and likely is
> being done in other packages we don't know about yet.
>
> With pickle, json, and __repr__, the usual way to write a test is to
> verify a roundtrip:  assert pickle.loads(pickle.dumps(data)) == data.  With
> XML, the problem is that the DOM doesn't have an equality operator.  The
> user is left with either testing specific fragments with
> element.find(xpath) or with using a standards compliant canonicalization
> package (not available from us). Neither option is pleasant.
>
> The code in the current 3.8 alpha differs from 3.7 in that it removes
> attribute sorting and instead preserves the order the user specified when
> creating an element.  As far as I can tell, there is no objection to this
> as a feature.  The problem is what to do about the existing tests in
> third-party code, what guarantees we want to make going forward, and what
> do we recommend as a best practice for testing XML generation.
>
> Things we can do:
>
> 1) Revert back to the 3.7 behavior. This of course, makes all the test
> pass :-)  The downside is that it perpetuates the practice of bytewise
> equality tests and locks in all implementation quirks forever.  I don't
> know of anyone advocating this option, but it is the simplest thing to do.
>
> 2). Go into every XML module and add attribute sorting options to each
> function that generate xml.  This gives users a way to make their tests
> pass for now. There are several downsides. a) It grows the API in a way
> that is inconsistent with all the other XML packages I've seen. b) We'll
> have to test, maintain, and document the API forever -- the API is already
> large and time consuming to teach. c) It perpetuates the notion that
> bytewise equality tests are the right thing to do, so we'll have this
> problem again if substitute in another code generator or alter any of the
> other implementation quirks (i.e. how CDATA sections are serialized).
>
> 3) Add a standards compliant canonicalization tool (see
> https://en.wikipedia.org/wiki/Canonical_XML ).  This is likely to be the
> right-way-to-do-it but takes time and energy.
>
> 4) Fix the tests in the third-party modules to be more focused on their
> actual test objectives, the semantics of the generated XML rather than the
> exact serialization.  This option would seem like the right-thing-to-do but
> it isn't trivial because the entire premise of the existing test is
> invalid.  For every case, we'll actually have to think through what the
> test objective really is.
>
> Of these, option 2 is my least preferred.  Ideally, we don't guarantee
> bytewise identical output across releases, and ideally we don't grow a new
> API that perpetuates the issue. That said, I'm not wedded to any of these
> options and just want us to do what is best for the users in the long run.
>
> Regardless of option chosen, we should make explicit whether on not the
> Python standard library modules guarantee cross-release bytewise identical
> output for XML. That is really the core issue here.  Had we had an explicit
> notice one way or the other, there wouldn't be an issue now.
>
> Any thoughts?
>
>
>
> Raymond Hettinger
>
>
> P.S.   Stefan Behnel is planning to remove attribute sorting from lxml.
> On the bug tr

Re: [Python-Dev] PEP 594 - a proposal for unmaintained modules

[David Mertz]

On Sun, May 26, 2019 at 11:17 PM Steven D'Aprano 
wrote:

> > Nobody reads warnings.
>
> If nobody reads warnings, we should just remove the warnings module and
> be done with it. That should probably be a PEP.
>

We'll have to start issuing a PendingDeprecationWarning when folk import
the `warnings` module. :-)

-- 
Keeping medicines from the bloodstreams of the sick; food
from the bellies of the hungry; books from the hands of the
uneducated; technology from the underdeveloped; and putting
advocates of freedom in prisons.  Intellectual property is
to the 21st century what the slave trade was to the 16th.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Re: python-ideas and python-dev migrated to Mailman 3/HyperKitty

[David Mertz]

The old URL is definitely a lot friendlier, even apart from the length. I
know at a glance the month and list where the thread occurred, which is
perhaps the most important metadata. In the new link I only know what
mailing list it happened on, and nothing else meaningful.

On Thu, Jun 6, 2019, 8:20 AM Steven D'Aprano  wrote:

> On Wed, Jun 05, 2019 at 11:08:13AM +0200, Victor Stinner wrote:
>
> > Enhancements:
> > * More reliable "permalink" URLs to emails
>
> This is excellent...
>
> but the old pipermail URLs were typically something like 70-80
> characters, which means they fit nicely into emails (and comments in
> source code). However the new URLs are much longer. Picking two examples
> at random:
>
> https://mail.python.org/pipermail/python-ideas/2019-March/055976.html
>
>
> https://mail.python.org/archives/list/python-id...@python.org/thread/B7QPHTQSBVN4NFO3SEVR57AIGYPM3MUM/
>
> i.e. 25-40% longer. Is there a shorter permalink form available, like
> goo.gl, bitly, youtu.be etc use? That would be awesome if we could use
> them instead.
>
>
>
> --
> Steven
> Python-Dev mailing list -- python-dev(a)python.org
> To unsubscribe send an email to python-dev-leave(a)python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/

[Python-Dev] Re: _Py_Identifier should support non-ASCII string?

[David Mertz]

This change would break two lovely functions I wrote this week.

On Thu, Jun 20, 2019, 12:35 PM Steve Dower  wrote:

> On 20Jun2019 0205, Inada Naoki wrote:
> > Hi, all.
> >
> > Both of PyUnicdoe_FromString() and _Py_Identifier are
> > supporting UTF-8 for now.  We can not change PyUnicode_FromString()
> > for backward compatibility,
> > so we have _PyUnicode_FromASCII instead.
> >
> > But _Py_Identifier is still private. And non-ASCII identifier
> > is not practical.
> > Can we change _PyUnicode_FromId to use _PyUnicode_FromASCII?
>
> What benefit would this provide? And why is a non-ASCII identifier not
> practical?
>
> Cheers,
> Steve
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/MTODUH26R6T3TEKYJOGQ2JTOVKPXRRIC/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/6BMPSO2GMOPYQWS4TUN3MCRUVJRGX4HO/

[Python-Dev] Re: _Py_Identifier should support non-ASCII string?

[David Mertz]

Ok. Good point. I used Unicode identifiers in my own project, not in
CPython. Some Greek letters that represent common mathematical concepts.

On Thu, Jun 20, 2019, 11:27 PM Inada Naoki  wrote:

> On Fri, Jun 21, 2019 at 6:55 AM David Mertz  wrote:
> >
> > This change would break two lovely functions I wrote this week.
> >
>
> Are your lovely functions in CPython, or in your project?
>
> _Py_Identifier is still private and undocumented.
> But I expect someone start using it outside of CPython.
> So I wanted to discuss we really need to support non-ASCII before that.
>
> But it seems I was late already.
>
> --
> Inada Naoki  
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/PCTTCDXGK6ZT633DPOS6YTPJVQLZJO5C/

[Python-Dev] Re: Comparing dict.values()

[David Mertz]

I agree with Greg.

There are various possible behaviors that might make sense, but having
`d.values() != d.values()` is about the only one I can see no sense in.

This really feels like a good cade for reading a descriptive exception. If
someone wants too compare `set(d.values())` that's great. If they want
`list(d.values())`, also a sensible question. But the programmer should
spell it explicitly.

This feels similar to NumPy arrays, that also will not compare for equality
in bare form. But they offer .any(), and .all() and other means of
expressing the comparison you actually want in a situation.

On Wed, Jul 24, 2019, 6:32 PM Greg Ewing 
wrote:

> Steven D'Aprano wrote:
> > Currently that assertion fails. Should it? Putting aside the convenience
> > of "do nothing, just inherit the object.__eq__ behaviour" do you think
> > that the current behaviour is *correct*?
>
> What I'm getting from this thread is that there are a variety of
> possible behaviours for dict values comparison, any of which could
> be considered "correct" depending on what the programmer is trying
> to do.
>
> I know there are good reasons for the guideline that equality
> comparisons should never raise exceptions, but this seems like a
> situation where Python really should slap you on the ear and
> make you specify exactly what you want.
>
> --
> Greg
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/WR2JGENQBL3EQ6ZUUFF2BPMMFTFDEH3R/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/ROEAXSGAQOAOCTI7WL57FO23DDXSPN4E/

[Python-Dev] Re: Comparing dict.values()

[David Mertz]

Exactly! that was my thought that the exception message could hint at
likely approaches. The NumPy example seems to have a good pattern:

arr1 == arr2

ValueError: The truth value of an array with more than one element is
ambiguous.

Use a.any() or a.all().


On Wed, Jul 24, 2019, 8:06 PM Rob Cliffe via Python-Dev <
python-dev@python.org> wrote:

>
>
> On 25/07/2019 00:09:37, David Mertz wrote:
> > I agree with Greg.
> >
> > There are various possible behaviors that might make sense, but having
> > `d.values() != d.values()` is about the only one I can see no sense in.
> +1
> >
> > This really feels like a good cade for reading a descriptive
> > exception. If someone wants too compare `set(d.values())` that's
> > great. If they want `list(d.values())`, also a sensible question. But
> > the programmer should spell it explicitly.
> >
> >
> So, a helpful error message including something like "Cannot compare
> dict.values directly, consider converting to sets / lists / sorted lists
> before comparing" ?
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/CSTSLCDEJYKDLADQV5PJRCSSVTMB5RIG/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/2IMLY36A6K45LHCXO2OVQJZBQKL47U6T/

[Python-Dev] Fwd: Re: Comparing dict.values()

[David Mertz]

On Thu, Jul 25, 2019 at 4:35 AM Petr Viktorin  wrote:

> It's not the equality operator that errors: `==` means element-wise
> comparison in Numpy. The error would come from a conversion of the array
> to bool:
>
>  >>> numpy.array([1, 2, 3]) == numpy.array([1, 3, 4])
> array([ True, False, False])
>
>  >>> if numpy.array([ True, False, False]):
> ... print('Same!')
> ...
> Traceback (most recent call last):
>File "", line 1, in 
> ValueError: The truth value of an array with more than one element is
> ambiguous. Use a.any() or a.all()
>

This is true of course.  I was being overly concise, but `arr1 == arr2`
does not itself (currently) raise any exception.  It's only `if arr1==arr2`
that does.

But what NumPy does is return a "special" object that has some methods to
convert it into a boolean in different ways.  We COULD do that with
`d1.values() == d2.values()` in principle.  This "DictValuesComparison"
object could have methods like `.equal_as_set()` and `.equal_as_list()`.
However, that's a lot of machinery for very little gain.

In contrast, a NumPy boolean array is useful for lots of purposes, and it
is something we want independently to have around.  Mostly it's a great way
of indexing into another list of numeric elements.  But it also can be used
in some less common, but not uncommon ways.  A hypothetical
DictValuesComparison object would have nearly no use other than avoiding
wrapping d.values() in list(), which we can already do fine.  Sure, maybe
that rare case could be made a little faster with this custom machinery,
but it doesn't feel worthwhile to me.

Therefore, I think the exception with guidance in the message should happen
at actual equality (or inequality) comparison time, not when casting to a
boolean context.

Numpy currently returns False when `==` “doesn't make sense”, but
> apparently has plans to change that:
>
>  >>> numpy.array([1, 2, 3]) == numpy.array([1, 2])
> __main__:1: DeprecationWarning: elementwise comparison failed; this will
> raise an error in the future.
> False
>
>  >>> numpy.array([1, 2, 3]) == numpy.array(['a', 'b'])
> __main__:1: FutureWarning: elementwise comparison failed; returning
> scalar instead, but in the future will perform elementwise comparison
> False
>

This is very interesting! I did not know about this planned change.  That
NumPy will start raising exceptions on equality comparison adds a little
bit of support for my suggestion, I think.


> > So, a helpful error message including something like "Cannot compare
> > dict.values directly, consider converting to sets / lists / sorted
> > lists before comparing" ?
>


-- 
Keeping medicines from the bloodstreams of the sick; food
from the bellies of the hungry; books from the hands of the
uneducated; technology from the underdeveloped; and putting
advocates of freedom in prisons.  Intellectual property is
to the 21st century what the slave trade was to the 16th.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/JBUS6FKXYUG4RTY2B6BUUO2DYNJT774Y/

[Python-Dev] Re: Fwd: Re: Comparing dict.values()

[David Mertz]

Yep! That's exactly my feeling too. Maybe add these to the "reasonable"
comparisons:

sorted(d1.values()) == sorted(d2.values())

Counter(d1.values()) == Counter(d2.values())

But generally everything I might want to compare about values has a
straightforward spelling already.

On Fri, Jul 26, 2019, 8:02 AM Greg Ewing 
wrote:

> David Mertz wrote:
> >
> > We COULD do that with
> > `d1.values() == d2.values()` in principle.  This "DictValuesComparison"
> > object could have methods like `.equal_as_set()` and
> > `.equal_as_list()`.  However, that's a lot of machinery for very little
> > gain.
>
> Particularly as there are already perfectly good ways to express those:
>
> set(d1.values()) == set(d2.values())
>
> list(d1.values()) == list(d2.values())
>
> --
> Greg
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/OHF54Z54D2ERD4L4P72JCJQ5EB3LS5XZ/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/CIZSAMTHRV524GZNWRUU6MCXMOUVRJ5E/

[Python-Dev] Words rather than sigils in Structural Pattern Matching

[David Mertz]

I have read a great deal of discussion on the pattern matching PEPs and
less formal discussions.  It is possible I have overlooked some post in all
of that, of course.

... OK, just saw Guido's "wait for new SC" comment, which I suppose applies
to this too :-).

One idea that I cannot recall seeing, but that seems to make sense to me
and fit with Python's feel is using a WORD to distinguish between a
variable value and a binding target.  That is, instead of a special symbol
prefixing or suffixing a name, either to indicate it is or is not a binding
target.  Of course, whether the extra word would be used for binding or for
NOT binding is a question still.

NOT_FOUND = 404
match http_code:
case 200:
print("OK document")
case value NOT_FOUND:  # use the variable value
print("Document not found")
case OTHER_CODE:  # bind this name
print("Other HTTP code", OTHER_CODE)

Of course, this would require a soft keyword, which is a disadvantage.
Going the other direction:

NOT_FOUND = 404
match http_code:
case 200:
print("OK document")
case NOT_FOUND:  # use the variable value
print("Document not found")
case bind OTHER_CODE:  # bind this name
print("Other HTTP code")

To me these read better than the punctuation characters.  But I guess some
folks have suggested enlisting 'as', which is a word, of course.




-- 
Keeping medicines from the bloodstreams of the sick; food
from the bellies of the hungry; books from the hands of the
uneducated; technology from the underdeveloped; and putting
advocates of freedom in prisons.  Intellectual property is
to the 21st century what the slave trade was to the 16th.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/5YUWE7K6LX3VZIISURABRBCEIGMYDUCS/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Pattern Matching controversy: Don't read PEP 635, read DLS'20 paper instead

[David Mertz]

Complimentary != Complementary

On Sun, Nov 15, 2020, 4:51 AM Paul Sokolovsky  wrote:

> Hello,
>
> As was mentioned many times on the list, PEP634-PEP636 are thoroughly
> prepared and good materials, many thanks to their authors. PEP635
> "Motivation and Rationale" (https://www.python.org/dev/peps/pep-0635/)
> stands out among the 3 however: while reading it, chances that you'll
> get a feeling of "residue", accumulating a section over section. By the
> end of reading, you may get a well-formed feeling that you've read a
> half-technical, half-marketing material, which is intended to "sell" a
> particular idea among many other very viable ideas, by shoehorning some
> concepts, downplaying other ideas, and at the same time, light-heartedly
> presenting drawbacks of its subject one.
>
> Just to give one example, literally at the very beginning, at the
> "Pattern Matching and OO" section (3rd heading) it says:
>
> > Pattern matching is complimentary to the object-oriented paradigm.
>
> It's not until the very end of document, in the "History and Context" it
> tells the whole truth:
>
> > With its emphasis on abstraction and encapsulation, object-oriented
> > programming posed a serious challenge to pattern matching.
>
> You may wonder how "complimentary" and "posed a serious challenge"
> relate to each other. While they're definitely not contradictory,
> starting the document with light-hearted "complimentary" can be seen as
> trying to set the stage where readers don't pay enough attention to the
> problem. And it kinda worked: only now [1] wider community discovers the
> implications of "Class Patterns" choices. (As a note, PEP635 does well
> on explaining them, and I'm personally sold on that, but it's *tough*
> choice, not the *obvious* choice).
>
> There're many more examples like that in the PEP635, would take too
> much space to list them all. However, PEP635 refers to the paper:
>
> > Kohn et al., Dynamic Pattern Matching with Python
> > https://doi.org/10.1145/3426422.3426983 (Accepted by DLS 2020. The
> > link will go live after Nov. 17; a preview PDF can be obtained from
> > the first author.)
>
> As that citation suggests, the paper is not directly linked from the
> PEP635. But the preprint is now accessible from the conference page,
> https://conf.researchr.org/home/dls-2020?#event-overview (direct link
> as of now: https://gvanrossum.github.io//docs/PyPatternMatching.pdf).
>
> That paper is written at much higher academic standard, and a pleasure
> to read. I recommend it to everyone who read PEP635 (note that it was
> written with PEP622 in mind, but conceptual differences are minor). With
> it, I noticed just 2 obvious issues:
>
>
> Section 4.3. Named Constants
>
> > It would clearly be desirable to allow named constants in patterns
> > as a replacement and extension of literals. However, Python has no
> > concept of a constant, i.e. all variables are mutable (even where
> > the values themselves are immutable).
>
> So, unlike PEP635, the paper pinpoints right the root of PEP634's
> problems: lack of constants in Python (on the language level). This is
> just the point which was raised on the mailing list either
> (
> https://mail.python.org/archives/list/python-dev@python.org/message/WV2UA4AKXN5PCDCSTWIUHID25QWZTGMS/
> ).
>
> Under strict academic peer review, the paper would have been returned
> for elaboration, with a note like: "Given that nowadays many dynamic
> languages (PHP, JavaScript, Lua, etc.) have support for constants, and
> lack of constants poses a serious usability challenge to your proposal,
> please explain why you chose to proceed anyway (and apply workarounds),
> instead of first introducing the concept of constants to the language.
> (Given that amount of work to implement pattern matching is certainly
> an order of magnitude larger than to introduce constants)."
>
> But the paper wasn't returned for elaboration, so we'll keep wondering
> why the authors chose such a backward process.
>
>
> Section 6.1. Scope
>
> > The granularity of the scope of local variables is at the level of
> > functions and frames. [...]
> > The only way to restrict the scope of a variable to part of a
> > function’s body (such as a case clause) would be to actively delete
> > the variable when leaving the block. This would, however, not restore
> > any previous value of a local variable in the function’s scope.
>
> This is a misconception ("the only way") which is repeated almost one
> to one on PEP635 either. If anything, the above describes how
> pseudo-scoping is currently implemented for exception vars in "except
> Exception as e:" clause (more info:
> https://mail.python.org/pipermail/python-dev/2019-January/155991.html),
> which is hardly a "best practice", and definitely not the only way.
>
> How to support multiple variable scopes in one stack frame is not a
> rocket science at all. One just need to remember how C did that since
> ~forever. And that's: (for unoptimized programs) variable

[Python-Dev] Re: The semantics of pattern matching for Python

[David Mertz]

On Sat, Nov 21, 2020 at 12:23 PM Steven D'Aprano 
wrote:

> Clearly Spam(a=1, b=2) does not necessarily result in an instance with
> attributes a and b. But the pattern `Spam(a=1, b=2)` is intended to be
> equivalent to (roughly):
>
> if (instance(obj, Spam)
> and getattr(obj, a) == 1
> and getattr(obj, b) == 2)
>
> it doesn't imply that obj was *literally* created by a call to
> the constructor `Spam(a=1, b=2)`, or even that this call would be
> possible.
>

I think this explanation makes me not worry about the fact that `Spam(a=1,
b=2)` in a pattern looks a lot like a constructor.  Like some other
commenters, I was vaguely bothered that the identical spelling might have
these different meanings in different contexts.  But I think a match case
just clearly enough IS a different context that using slightly different
intuitions is no real conceptual stretch for remembering or teaching it.

As a strawman, we could use different syntax for "match the thing of class
Spam that has attributes with these values:

match eggs:
case Spam[a=1, b=2]: ...

Or:

match eggs:
case Spam{a=1, b=2}: ...

Well, the square brackets COULD mean something different if PEP 637 is
adopted.  But even supposing the curly braces could be fit into the
grammar.  Yes, it sort of suggests the connection between dictionaries and
Spam.__dict__.  But it still reads as "this is something special that I
have to think about a little differently."

Even where there are capture variables, I think I'd be completely
comfortable thinking about the different context for:

match eggs:
case Spam(a=x, b=2): ...

-- 
The dead increasingly dominate and strangle both the living and the
not-yet born.  Vampiric capital and undead corporate persons abuse
the lives and control the thoughts of homo faber. Ideas, once born,
become abortifacients against new conceptions.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/XSRVX2NTDGUF7CWTPR5SHIOAQPWNXXYZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Words rather than sigils in Structural Pattern Matching

[David Mertz]

I'm not sure it matters in all the threads.  But my underlying opinion is
that we SHOULD have a mechanism to use a plain name (that has an assigned
value in the scope) as a value in match patterns, not only as binding
targets.

However, in contrast to Nick Coghlan, I do not think access should be the
default, but that binding should be.  I'm convinced by Guido, Brandt, and
others that the binding  use will be far more common, so adding extra
characters for the 90% case does not feel desirable, even if it is arguably
more consistent with other elements of the language.

The second example I give of binding requiring the extra syntax was for
completeness, but I would not support it myself.  If binding were to
require extra syntax, I think Nick's 'as' suggestion is better than my
prefix word idea (if only because it doesn't need a new soft keyword).  I
do not think the answer of "put the plain name into an enumeration or other
object so it can be accessed as a dotted name" is quite enough.  Yes,
that's possible, but it feels more forced.

So in my mind, if I had the choice, it is a decision between a sigil and a
word to indicate "no, really use this name as a value!" I like a word
better, but none of the current keywords really make sense, so it would
need to be a new word. I suggested "value", but another word might be
better.

On Thu, Nov 12, 2020 at 7:38 PM David Mertz  wrote:

> One idea that I cannot recall seeing, but that seems to make sense to me
> and fit with Python's feel is using a WORD to distinguish between a
> variable value and a binding target.  That is, instead of a special symbol
> prefixing or suffixing a name, either to indicate it is or is not a binding
> target.  Of course, whether the extra word would be used for binding or for
> NOT binding is a question still.
>
> NOT_FOUND = 404
> match http_code:
> case 200:
> print("OK document")
> case value NOT_FOUND:  # use the variable value
> print("Document not found")
> case OTHER_CODE:  # bind this name
> print("Other HTTP code", OTHER_CODE)
>
> Of course, this would require a soft keyword, which is a disadvantage.
> Going the other direction:
>
> NOT_FOUND = 404
> match http_code:
> case 200:
> print("OK document")
> case NOT_FOUND:  # use the variable value
> print("Document not found")
> case bind OTHER_CODE:  # bind this name
> print("Other HTTP code")
>
> To me these read better than the punctuation characters.  But I guess some
> folks have suggested enlisting 'as', which is a word, of course.
>
>
>
>
> --
> Keeping medicines from the bloodstreams of the sick; food
> from the bellies of the hungry; books from the hands of the
> uneducated; technology from the underdeveloped; and putting
> advocates of freedom in prisons.  Intellectual property is
> to the 21st century what the slave trade was to the 16th.
>


-- 
The dead increasingly dominate and strangle both the living and the
not-yet born.  Vampiric capital and undead corporate persons abuse
the lives and control the thoughts of homo faber. Ideas, once born,
become abortifacients against new conceptions.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/WAGBJUKGS5V7AGUYDWNZAI5NNA76MXYN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Words rather than sigils in Structural Pattern Matching

[David Mertz]

On Sat, Nov 21, 2020 at 2:47 PM Guido van Rossum  wrote:

> On Sat, Nov 21, 2020 at 9:52 AM David Mertz  wrote:
>
>> So in my mind, if I had the choice, it is a decision between a sigil and
>> a word to indicate "no, really use this name as a value!" I like a word
>> better, but none of the current keywords really make sense, so it would
>> need to be a new word. I suggested "value", but another word might be
>> better.
>>
>
> The good news here is that the PEP 634 syntax is sufficiently restricted
> that we can always add this later, regardless of whether we end up wanting
> a sigil or a (soft) keyword, as long as we agree that the meaning of a bare
> name should be a capture variable.
>

I thought of that.  An incremental approach of accepting PEP 634, but
(perhaps) adding a soft keyword later is probably the most sensible thing.

If the "need the value of a plain name" is a 1% case, a workaround like
putting it into an attribute of some object before matching is a minor
issue.  If that's the 25%+ case, after experience, the argument for some
annotation of "use the value" could be added later.


-- 
The dead increasingly dominate and strangle both the living and the
not-yet born.  Vampiric capital and undead corporate persons abuse
the lives and control the thoughts of homo faber. Ideas, once born,
become abortifacients against new conceptions.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/Q7NUDCGLH2OCRK5XJ5QEEOIZ4FECKPGO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Advantages of pattern matching - a simple comparative analysis

[David Mertz]

On Mon, Nov 23, 2020, 2:58 PM Ethan Furman

>  >>  if isinstance(node, StringNode):
>  >>  return node.value
>  >>  elif isinstance(node, NumberNode):
>  >>  return float(node.value)
>  >>  elif isinstance(node, ListNode):
>  >>  return [process_node(child_node) for child_node in
> node.children]
>  >>  elif isinstance(node, DictNode):
>  >>  return {key: process_node(child_node) for key, child_node
> in node.children}
>  >>  else:
>  >>  raise Exception('Unexpected node')
>  >
>  > You don't need the "else".
>
> Without the "else" errors will pass silently.
>

Not in the particular example. It can just be a bunch of ifs, each of which
returns something. The last line of the function can be raise.

Obviously, epic and else are very important in general. I think I wouldn't
use any for that particular code though.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/DIOGB53TRPJ3A2AN4AQIHU4WLDR5776U/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Advantages of pattern matching - a simple comparative analysis

[David Mertz]

I have a little bit of skepticism about the pattern matching syntax, for
similar reasons to those Larry expresses, and that Steve Dower mentioned on
Discourse.

Basically, I agree matching/destructuring is a powerful idea.  But I also
wonder how much genuinely better it is than a library that does not require
a language change.  For example, I could create a library to allow this:

m = Matcher(arbitrary_expression)
if m.case("StringNode(s)"):
process_string(m.val)
elif m.case("[a, 5, 6, b]"):
process_two_free_vars(*m.values)
elif m.case("PairNone(a, b)"):
a, b = m.values
process_pair(a, b)
elif m.case("DictNode"):
foo = {key, process_node(child_node) for key, child_node in
m.values.items()}

I don't disagree that the pattern mini-language looks nice as syntax.  But
there's nothing about that mini-language that couldn't be put in a library
(with the caveat that patterns would need to be quoted in some way).

-- 
The dead increasingly dominate and strangle both the living and the
not-yet born.  Vampiric capital and undead corporate persons abuse
the lives and control the thoughts of homo faber. Ideas, once born,
become abortifacients against new conceptions.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/TUXJFRSCW2JOYTU5F6TVGPH6X5SRDJOB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Advantages of pattern matching - a simple comparative analysis

[David Mertz]

On Mon, Nov 23, 2020 at 9:02 PM Brian Coleman 
wrote:

> > Basically, I agree matching/destructuring is a powerful idea.  But I also
> > wonder how much genuinely better it is than a library that does not
> require
> > a language change.  For example, I could create a library to allow this:
>


>  m = Matcher(arbitrary_expression)
>  if m.case("StringNode(s)"):
> process_string(m.val.s)
>  elif m.case("[a, 5, 6, b]"):
> process_two_free_vars(m.val.a, m.val.b)


> What you are proposing here is very similar in effect to executing pattern
> matching statements using `eval`. What is the advantage of implementing the
> pattern matching functionality in a library if the user interface for that
> functionality has the same pitfalls as `eval`?
>

I don't understand the similarity with `eval` that you are suggesting.

My hypothetical library would store the value passed as initializer to
`Matcher`, and provide a method `.case()`.  That method would need to do
some moderately complicated parsing of the pattern passed into it, but
using parsing techniques, not any eval() call.  Btw. I modified my above
strawman just slightly to what might be a bit better API.

If there are any free variables in the pattern, they would be provided by
the Matcher object.  For example, they could be attributes of the property
`m.val`.  Or I suppose we could make them attributes of the Matcher object
itself, e.g. `m.a` and `m.b`, but I think name conflicts with e.g.
`m.case`.  Anyway, it's a strawman not an API design.

If the pattern looked kinda like a class constructor (i.e. exactly the same
as PEP 634 rules), the `.case()` method would do an `isinstance()` check
before doing its other stuff.  If the pattern looks like a list, it would
scan the freevars inside it and match the constant values.  And so on.

The actual return value from `.m.case(...)` would be True or False (or at
least something truthy or falsy).  However, it MIGHT create some new
attributes (or keys, or something else) on the Matcher object if the
pattern actually matched.

I agree the above is slightly less readable than PEP 635 syntax, but it
seems to have the entire power of the proposal without changing Python
syntax.

-- 
The dead increasingly dominate and strangle both the living and the
not-yet born.  Vampiric capital and undead corporate persons abuse
the lives and control the thoughts of homo faber. Ideas, once born,
become abortifacients against new conceptions.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/7KIN2LEWBR4P6TI57QAA263HDXSFG4YZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Advantages of pattern matching - a simple comparative analysis

[David Mertz]

On Mon, Nov 23, 2020, 4:32 PM Eric V. Smith

> I just commented on Steve's post over on Discourse. The problem with this
> is that the called function (m.case, here) needs to have access to the
> caller's namespace in order to resolve the expressions, such as StringNode
> and PairNone. This is one of the reasons f-strings weren't implemented as a
> function, and is also the source of many headaches with string type
> annotations.
>
Is this really true though? Yes, it would require magic of the sort
zero-argument `super()` does. But can't the Matcher constructor capture the
locals one step up the stack on instance creation? That's largely why my
strawman version is slightly different from Steve's strawman.

I'd put the question this way: assuming Matcher can be written (with a bit
of stack magic), and assuming that the strings inside m.case() calls are
exactly the same mini-languague PEP 634 proposes, would you want a syntax
change?

That's not rhetorical, I'm of mixed feeling myself.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/ZQBAYYR5KJFJVXVYQQ3TIS5JLJZDM3K3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Advantages of pattern matching - a simple comparative analysis

[David Mertz]

>
> I'd put the question this way: assuming Matcher can be written (with a bit
> of stack magic), and assuming that the strings inside m.case() calls are
> exactly the same mini-languague PEP 634 proposes, would you want a syntax
> change?
>
> No, I wouldn't!
>
Is one of us mixing up negations? Are you saying you do NOT support PEP 634
(i.e. syntax change)?

A reasonable enough opinion that several core developers hold. Just trying
to understand.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/RFWLULNGRNEYSAGQ2KKAT3ZUFBEU2BFV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: nanosecond stat fields, but not os.path methods ?

[David Mertz]

Are there any filesystems that can actually record a meaningful ns
modification time?  I find discussions claiming this:

- XFS and EXT3: second precision
- EXT4: millisecond precision
- NTFS: 100ns precision
- APFS: 1 ns precision

But also notes that the precision is likely to exceed the accuracy by many
times on real systems.

On Mon, Dec 7, 2020 at 2:34 PM Mats Wichmann  wrote:

>
> there are stat fields now for ns precision, e.g. st_mtime now has an
> analogue st_mtime_ns.  But os.path didn't grow corresponding methods -
> there's an os.path.getmtime but not _ms. Was that intentional?  The
> wrappers in genericpath.py are trivial and arguably aren't particularly
> needed, but still curious...
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/CK3S2DYI3PKZ7VGRFEO4PKVLZCPUTR6N/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
The dead increasingly dominate and strangle both the living and the
not-yet born.  Vampiric capital and undead corporate persons abuse
the lives and control the thoughts of homo faber. Ideas, once born,
become abortifacients against new conceptions.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/ZAPQSEQHL3KO7AALG7NQTIA2BPG753AN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: SC 2020 recommendation for PEP 634

[David Mertz]

As a candidate for the new SC, if elected I would certainly find it more
useful to have more specific thoughts from the outgoing SC than simply "we
recommend." How divided was the vote? Who took the sides? What were the
major points of disagreement? That sort of thing.

On Tue, Dec 8, 2020 at 9:39 AM Antoine Pitrou  wrote:

> On Mon, 7 Dec 2020 11:29:55 -0800
> Brett Cannon  wrote:
> > After much deliberation, the 2020 SC will be making a recommendation to
> the
> > 2021 SC to accept PEP 634 (although this was not a unanimous decision).
> > This is in no way a binding recommendation to the 2021 SC (even if a
> > majority of current council members get re-elected), but we felt we
> should
> > pass on our thoughts to the next council as we have been discussing
> pattern
> > matching for a few months at this point and we promised we would make
> some
> > decision to the PEP authors.
>
> Perhaps you could also post the thought process which leads to this
> recommendation, so that the future SC has more input on the matter?
>
> Regards
>
> Antoine.
>
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/FTXGXG6UEULVIU56WAYLBEWMX6ZBFKXA/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
The dead increasingly dominate and strangle both the living and the
not-yet born.  Vampiric capital and undead corporate persons abuse
the lives and control the thoughts of homo faber. Ideas, once born,
become abortifacients against new conceptions.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/RBDVJINV5KVIWSGO57CR7ENN2OG2VE3F/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: unittest of sequence equality

[David Mertz]

On Tue, Dec 22, 2020 at 6:57 PM Alan G. Isaac  wrote:

> The following test fails because because `seq1 == seq2` returns a
> (boolean) NumPy array
> whenever either seq is a NumPy array.
>
>  import unittest
>  import numpy as np
>  unittest.TestCase().assertSequenceEqual([1.,2.,3.],
> np.array([1.,2.,3.]))
>
> I expected `unittest` to rely only on features of a
> `collections.abc.Sequence`,
> which based on https://docs.python.org/3/glossary.html#term-sequence,
> I believe are satisfied by a NumPy array.


If you know you might be dealing with NumPy arrays (as the import
suggests), I think it's simply right to spell it as:

unittest.TestCase().assertTrue(np.array_equal([1., 2., 3.], np.array([1.,
2., 3.])))

Or for pytest etc., simply:

assert np.array_equal([1., 2., 3.], np.array([1., 2., 3.]))
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/JJHAURGJCFG5PZUQFOUPTJWXGQABOSBT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: unittest of sequence equality

[David Mertz]

On Tue, Dec 22, 2020 at 11:44 PM Alan G. Isaac  wrote:

> My question is not about work arounds.
> It is about whether the current definition of a sequence
> (in collections.abc) should govern `assertSequenceEqual`.
>

Why do you think a NumPy array is a sequence?

E.g.:

>>> a
array([[1, 2],
   [3, 4]])
>>> b
[1, 2]
>>> len(a) = len(b)

 Ok, I suppose if you then loop through indices, you indeed get different
things.  But N-dimensional arrays aren't "indexed by an integer" except in
the sense of an edge case.  I've always read the Glossary as more narrowly
"element access using ONLY integer indices."

Moreover, if you propose to ignore `==` comparison and always loop, will
you do so recursively?  What about:

assertSequenceEqual(a, [[1,2], [3,4]])

-- 
The dead increasingly dominate and strangle both the living and the
not-yet born.  Vampiric capital and undead corporate persons abuse
the lives and control the thoughts of homo faber. Ideas, once born,
become abortifacients against new conceptions.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/VMKUC6LDGDPURJ5PN7T7FKOASN2M4NZR/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 647 (type guards) -- final call for comments

[David Mertz]

On Sun, Feb 14, 2021, 2:53 PM Gregory P. Smith  wrote:

> *TL;DR of my TL;DR* - Not conveying bool-ness directly in the return
> annotation is my only complaint.  A BoolTypeGuard spelling would
> alleviate that.
>

This is exactly my feeling as well. In fact, I do not understand why it
cannot simply be a parameterized Bool. That would avoid all confusion. Yes,
it's not the technical jargon type system designers use... But the existing
proposal moves all the mental effort to non-experts who may never use type
checking tools.

I.e. if I read this:

def is_str_list(v: List[Any]) -> Bool[List[str]]:
...

I just think, "OK, it returns a bool, and those mypy people are doing
something else funny that I don't need to worry about." If I see
TypeGuard[...whatever..] I automatically think "that's a weird thing I
don't understand, but it looks like it returns a boolean when I read the
body."

FWIW, this hypothetical non-expert is me. I've actually gotten in the habit
of using simply type annotations in most of the code I write (a lot of
which is for teaching). But I never actually check using type checkers.
It's quite likely some of my annotations are not actually sound, but to me
they are documentation. I.e. I'll use an annotation of str/list/float, but
not precisely parameterized types, union, generics, etc.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/SX2FB46PIQZCHNEQWE6ATPWCX66R65TG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 647 (type guards) -- final call for comments

[David Mertz]

On Sun, Feb 14, 2021, 5:34 PM Guido van Rossum  wrote:

> But note that 'bool' in Python is not subclassable.
>

Sure. But that's why I suggested 'Bool' rather than 'bool'. It's a
different spelling, but one with a really obvious connection.

>
> I.e. if I read this:
>>
>> def is_str_list(v: List[Any]) -> Bool[List[str]]:
>> ...
>>
>> I just think, "OK, it returns a bool, and those mypy people are doing
>> something else funny that I don't need to worry about."
>>
>
>> So maybe you should just stick to "bool". TypeGuard is really only useful
> for people who care about what type checkers do (a surprisingly large
> contingent, actually, but I would not recommend it for the education
> department).
>

I'm fairly sure I *will* just stick with 'bool' in code I write, no matter
the outcome of this PEP. But I'm also sure I'll read code written by other
people in the future... And EXPLAIN code written by other people to people
less knowledgeable than I am.

When explaining code to students or junior colleagues, it feels MUCH easier
to explain "Bool[...] is a funny way of spelling 'bool' (in annotations)"
than explaining the same of TypeGuard [...].
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/XAFHBVTZAT5CASC6QTZFGTSJ5DTHLLM5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Python 0.9.1

[David Mertz]

Will someone publish an manylinux build to conda-forge (or their own
channel)?

On Thu, Feb 18, 2021 at 9:15 PM Dan Stromberg  wrote:

>
> On Thu, Feb 18, 2021 at 12:02 AM Paul Sokolovsky 
> wrote:
>
>> I think to resolve this issue to the completion, and avoid possibility
>> of an intermediary to add any unexpected changes/mistakes to the
>> original sources, instead of "someone making a tarball", someone should
>> make a script, which reproduces making a tarball. Then such a script
>> can be reviewed and tarball reproduced independently (e.g., by the
>> admins of python.org).
>>
>> That's exactly what I did, and attached it to the ticket above:
>> https://github.com/python/pythondotorg/issues/1734#issuecomment-781129337
>>
>> For extra details, copying my comment there:
>>
>> ---
>> I attach my version of such a script (and also paste it below for
>> reference, but if you use it, please use the attached version to avoid
>> any discrepancies due to copy-paste).
>>
>
> I got a version to build, but what's supposed to be in patchlevel.h?  It
> was just an int, but that was confusing gcc.  I commented out its #include,
> and things seemed to work without it.  The patches I used are at
> https://stromberg.dnsalias.org/svn/cpythons/trunk/python0.9/exportable-patches
>
> Sadly, it doesn't work that well with my "pythons" script (
> https://stromberg.dnsalias.org/~strombrg/pythons/), because 0.9.1's
> interpreter doesn't have a -c option.
>
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/XAKEELGLCWOVW77F4PV2S6MYSC7YFXZR/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
The dead increasingly dominate and strangle both the living and the
not-yet born.  Vampiric capital and undead corporate persons abuse
the lives and control the thoughts of homo faber. Ideas, once born,
become abortifacients against new conceptions.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/YUHJS66CKPUAJVBOKVMEWKXBVTBV3EH2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Python 0.9.1

[David Mertz]

I've provided this excellent language interpreter as a conda package.  For
users of conda, you can install it (on Linux) with:

conda install -c davidmertz python=0.9

(perhaps put it in a different environment than base).

I'm embarrassed by how much effort that took me. I used to teach
conda-build at Anaconda, but I've forgotten everything about how it works.
There may have been another way to do it, but what this installs uses a
hack.  There might have been some other way to do this, but:

% cat `which python`
#!/bin/bash
PYTHONPATH=$CONDA_PREFIX/lib/ python-0.9.1

The manpage works though. As Skip pointed out to me privately, there are
some minor limitations with this version.  E.g.:

% python
>>> import glob
>>> import sys
>>> print 'hello'
hello
>>> print 2+2
4
>>> print 2*2
Unhandled exception: run-time error: integer overflow
Stack backtrace (innermost last):
  File "", line 1

It's easy enough to work around that though:

>>> def mult(a, b):
... total = 0
... for _ in range(a):
... total = total + b
... return total
...
>>> mult(2, 2)
4


On Tue, Feb 16, 2021 at 10:01 PM Skip Montanaro 
wrote:

> A note to webmas...@python.org from an astute user named Hiromi in Japan* 
> referred
> us to Guido's shell archives for the 0.9.1 release from 1991. As that
> wasn't listed in the historical releases README file:
>
> https://legacy.python.org/download/releases/src/README
>
> I pulled the shar files (and a patch), then made a few tweaks to get it to
> build:
>
> % ./python
> >>> print 'hello world!'
> hello world!
> >>> import sys
> >>> dir(sys)
> ['argv', 'exit', 'modules', 'path', 'ps1', 'ps2', 'stderr', 'stdin',
> 'stdout']
> >>> sys.modules
> {'builtin': ; 'sys': ; '__main__':  '__main__'>}
> >>> sys.exit(0)
>
> I then pushed the result to a Github repo:
>
> https://github.com/smontanaro/python-0.9.1
>
> There is a new directory named "shar" with the original files, a small
> README file and a compile.patch file between the original code and the
> runnable code.
>
> It was a pleasant diversion for a couple hours. I was tired of shovelling
> snow anyway... Thank you, Hiromi.
>
> Skip
>
> *  Hiromi is bcc'd on this note in case he cares to comment. I didn't want
> to publish his email beyond the bounds of the webmaster alias without his
> permission.
>
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/VZYELIYAQWUHHGIIEPPJFREDX6F24KMN/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
The dead increasingly dominate and strangle both the living and the
not-yet born.  Vampiric capital and undead corporate persons abuse
the lives and control the thoughts of homo faber. Ideas, once born,
become abortifacients against new conceptions.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/6HRFITORPFZBO6V7VQ5AAVDIEVFNWHQ6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Python 0.9.1

[David Mertz]

In conversation with Dan, I have fixed my conda package (but overwritten
the same version).  I needed to add this to the build:

# sudo apt-get install gcc-multilib
CC='gcc -m32' make python

I don't have 32-bit headers by default anymore on my distro.  With that
change, I can run:

% conda install -c davidmertz python=0.9
% python
>>> 2*2
4

Dan sent me links to some patches he developed himself, but I have not
applied them.  I'm not doubting that they are good and useful, but I'm
trying to make something as close as possible to what was actually first
released.

-- 
The dead increasingly dominate and strangle both the living and the
not-yet born.  Vampiric capital and undead corporate persons abuse
the lives and control the thoughts of homo faber. Ideas, once born,
become abortifacients against new conceptions.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/3B4EW5IF6OQ33CQRGXC3H57LG3KSQ6F5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Steering Council update for February

[David Mertz]

On Wed, Mar 10, 2021 at 1:13 PM Evpok Padding 
wrote:

> Apparently renaming a git branch to follow the general convention is now
> an unbearable outrage. It strikes me as a somewhat odd hill to die on, but
> okay. However there is a code of conduct that is supposed to be followed
> here https://www.python.org/psf/conduct. Let me quote
>
> > Examples of unacceptable behavior by participants include: […] Insults,
> put downs, or jokes that are based upon stereotypes, that are exclusionary,
> or that hold others up for ridicule
>

Renaming main branches as 'main' is currently predominant practice on
GitHub (and more broadly in Free Software communities).  Python doesn't
need to cling to an old name based on a tired argument that political
sensitivity is a creeping plot to destroy old "fun" prejudices and
injustices.

Yes, in Latin the sense of 'magister' was "teacher" fairly neutrally.  That
is not more accurate for the source control intent than is 'main'.  This
passes through both the Old French 'maistre' with pretty much the Latin
meaning, as well as through Old English 'maegister'.  By the time of Middle
English in the mid-14th century CE, the sense of "dominance" is the
predominant one, specifically in the patriarchal meaning of "male head of a
household" prior to the Atlantic Slave Trade (also not an insinuation we
wish to promote).

It even has a symbol for chains, which is associated even more closely
>> with slavery than "master".
>>
>
All the other examples are also forced and contrived.  This is perhaps
worst.  I own several chains for purposes having nothing to do with bondage
or oppression. Towing a car, hanging a bird feeder, and affixing a fence
gate are well served by interlocked loops of metal.  Which is honestly, a
pretty good skeuomorphic mnemonic for what ChainMap does.


-- 
The dead increasingly dominate and strangle both the living and the
not-yet born.  Vampiric capital and undead corporate persons abuse
the lives and control the thoughts of homo faber. Ideas, once born,
become abortifacients against new conceptions.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/GZGV7B2KL6XTIRP7UJWPGBJFKFZF4QUR/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Steering Council update for February

[David Mertz]

On Wed, Mar 10, 2021, 4:30 PM Steven D'Aprano  wrote:

> > All the other examples are also forced and contrived.  This is perhaps
> worst.  I own several chains for purposes having nothing to do with bondage
> or oppression.
>
> Chains are an almost universal symbol of bondage and slavery: "Man is
> born free but everywhere he is in chains", according to Rosseau (please
> forgive the sexism, his sense was mankind as a whole regardless of sex
> or gender). How is this contrived? Not just contrived, but the "worst"
> example of it.
>

I think you actually understand this and are feigning for rhetorical effect.

ChainMap is suggestive of "sequential interlocked pieces." Obviously, what
it does isn't identical to the actual metal construct, but it's reminiscent
though.

I could imagine that that some other name of a software object could be
named after chains as used in human bondage. But this one simply isn't. I
genuinely cannot think of any way metaphorically to connect ChainMap to
that.

In contrast, the "master" used in version control directly borrows from
so-called "master/slave network architecture." I saw in this thread one
implausible argument that it was intended in the sense of "magister." I
don't believe it, but even if we stipulate that whoever first used the word
in relation to version control meant that, nearly everyone else who
discusses it means "master/slave."

I can also imagine some very different software object that used a
different sense. If something else really did invoke "master key" (a key
that fits all the locks), that might be innocuous. But again, that sense
makes no sense in relation to version control, and no one believes that is
the meaning.

>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/KLKYYQFSYFG3CQV2JMW4LOUG7FC7NUXJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Boundaries between numbers and identifiers

[David Mertz]

I feel like all of these examples, if found in the wild, are far more
likely to be uncaught bugs than programmer intent. Being strict about
spaces (or parents, brackets, etc. in other contexts) around numbers is
much more straightforward than a number of edge cases where is not obvious
what will happen.

On Tue, Apr 13, 2021, 6:24 PM Barry Warsaw  wrote:

> On Apr 13, 2021, at 12:52, Serhiy Storchaka  wrote:
> >
> > New example was found recently (see https://bugs.python.org/issue43833).
> >
>  [0x1for x in (1,2)]
> > [31]
> >
> > It is parsed as [0x1f or x in (1,2)] instead of [0x1 for x in (1,2)].
>
> That’s a wonderfully terrible example!  Who’s maintaining the list? :D
>
> -Barry
>
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/7JXD7SOHACL5SFTA4SBIOWPEG625LD34/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/KMWEK2OLJ34PD3QE5XKTOVMSHCXC4TJA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Revive PEP 396 -- Module Version Numbers ?

[David Mertz]

I recently encountered this, which is very useful, but only for a
human-readable perspective.

>>> import vaex
>>> vaex.__version__
{'vaex': '4.1.0', 'vaex-core': '4.1.0', 'vaex-viz': '0.5.0', 'vaex-hdf5':
'0.7.0', 'vaex-server': '0.4.0', 'vaex-astro': '0.8.0', 'vaex-jupyter':
'0.6.0', 'vaex-ml': '0.11.1'}



On Wed, Apr 14, 2021 at 2:01 PM Barney Gale  wrote:

> > In my Python projects, I like to provide the version as a tuple which
> > can be used directly for comparison
>
> To add to this, comparing tuples doesn't always work well for projects
> where multiple release lines are maintained simultaneously, e.g.
> user-facing changes introduced in minor/point releases across several major
> versions. People use version numbers in wildly different ways.
>
> Barney
>
> On Wed, 14 Apr 2021 at 13:26, Victor Stinner  wrote:
>
>> On Wed, Apr 14, 2021 at 7:48 AM Christopher Barker 
>> wrote:
>> > So what do you'all think? After thirteen years, it would be nice to put
>> this to bed.
>>
>> There are two main use cases for versions:
>>
>> * Display them to the user
>> * Compare versions to check if one is newer, older or the same
>>
>> I dislike using strings for comparison. You need to use
>> packaging.version for that:
>> https://packaging.pypa.io/en/latest/version.html
>>
>> Many C libraries provide the version as a number of as 3 numbers
>> (major, minor, micro). In its C API, Python provides all of them:
>>
>> * PY_VERSION_HEX: single number
>> * (PY_MAJOR_VERSION, PY_MINOR_VERSION, PY_MICRO_VERSION,
>> PY_RELEASE_LEVEL, PY_RELEASE_SERIAL): as 5 numbers
>> * PY_VERSION: string
>>
>> In my Python projects, I like to provide the version as a tuple which
>> can be used directly for comparison: version_a <= version_b. Example:
>>
>> VERSION = (2, 2, 1)
>> __version__ = '.'.join(map(str, VERSION))
>>
>> The tuple might contain strings like "beta" or "rc", as soon as
>> comparison makes sense ;-) Sadly, such tuple is no standardized. Which
>> part is the major version? How to format it as a string?
>>
>> Good luck with trying to standardize that ;-)
>>
>> Victor
>> --
>> Night gathers, and now my watch begins. It shall not end until my death.
>> ___
>> Python-Dev mailing list -- python-dev@python.org
>> To unsubscribe send an email to python-dev-le...@python.org
>> https://mail.python.org/mailman3/lists/python-dev.python.org/
>> Message archived at
>> https://mail.python.org/archives/list/python-dev@python.org/message/MBBYB5AWX76O3TOUFATRKSU2QND2TPKS/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/4XWIWIKDJJRWVKNGIOENJ2ZJVQR4PP23/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
The dead increasingly dominate and strangle both the living and the
not-yet born.  Vampiric capital and undead corporate persons abuse
the lives and control the thoughts of homo faber. Ideas, once born,
become abortifacients against new conceptions.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/YNQ2QSJ35B2IAAQ2YCTKH2NJYNQD4DZK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Revive PEP 396 -- Module Version Numbers ?

[David Mertz]

Agreed!

I was trying to figure out why an API from Vaex 3.x was no longer working,
and to my human eye, this quickly pointed me at the issue.  However as a
way to automatically check for versions, this is a mess.  I have no idea
what additional keys the next version might add or remove, for example.
I'm not even sure if this is dynamically determined based on optional
components being installed or not.

Providing this kind of information *somehow* feels like a useful thing to
do.  But .__version__ is probably not the right way to do it.

On Wed, Apr 14, 2021 at 5:08 PM Christopher Barker 
wrote:

> On Wed, Apr 14, 2021 at 7:48 AM David Mertz  wrote:
>
>> >>> vaex.__version__
>> {'vaex': '4.1.0', 'vaex-core': '4.1.0', 'vaex-viz': '0.5.0', 'vaex-hdf5':
>> '0.7.0', 'vaex-server': '0.4.0', 'vaex-astro': '0.8.0', 'vaex-jupyter':
>> '0.6.0', 'vaex-ml': '0.11.1'}
>>
>
> Well, THAT is a great argument for some official standardization!
>
> There is sometimes a need for that sort of thing, but I think it's best
> handled by either putting __version__ in each sub_package, or having a
> different attribute altogether.
>
> -CHB
>
> --
> Christopher Barker, PhD (Chris)
>
> Python Language Consulting
>   - Teaching
>   - Scientific Software Development
>   - Desktop GUI and Web Development
>   - wxPython, numpy, scipy, Cython
>


-- 
The dead increasingly dominate and strangle both the living and the
not-yet born.  Vampiric capital and undead corporate persons abuse
the lives and control the thoughts of homo faber. Ideas, once born,
become abortifacients against new conceptions.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/CWEX6QRKSB3E3IYHTPUMIMY6WCYIR7FK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Revive PEP 396 -- Module Version Numbers ?

[David Mertz]

On Wed, Apr 14, 2021 at 5:44 PM Christopher Barker 
wrote:

> Another possible issue: using Version would require an extra import in
> many module initializations -- is that a performance issue that would
> matter?
>

I like having a `Version` object that is easily importable in the standard
library.  I think it should relatively polymorphic.  I.e. it should accept
a module or package as an argument, but also should accept a string or a
tuple.  Maybe other objects from which one could reasonably extract a
version.

In particular, I think initializing this object with a module object should
at least look for a .__version__ attribute, and appropriately case either a
string (that looks sufficiently version-like) or a tuple.  I think that if
it doesn't succeed, it should become some sort of "cannot determine" object
that is neither less than nor greater than any other Version object.  In
particular, the Vaex example with a dictionary of versions of each
component should probably just become this "cannot determine" value (but as
an instance of Version).

-- 
The dead increasingly dominate and strangle both the living and the
not-yet born.  Vampiric capital and undead corporate persons abuse
the lives and control the thoughts of homo faber. Ideas, once born,
become abortifacients against new conceptions.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/S6ZHCQ57ZH5OMLBQK5LWMZUTT7HEARPV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Revive PEP 396 -- Module Version Numbers ?

[David Mertz]

On Wed, Apr 14, 2021 at 9:12 PM Paul Moore  wrote:

> If it's not basically equivalent to packaging.version.Version (and
> based on PEP 440) then we'll be creating a nightmare of confusion,
> because PEP 440 versions are fundamental to packaging.
>

Are you suggesting that users should have to install an external module to
tell what version of packages they are using?!

What's wrong with Version(module.__version__)? And if the __version__
> attribute isn't a valid version, raise an exception? That's what
> packaging.version does, and it's worked fine for the packaging
> ecosystem. Is there a benefit that justifies being different here?
>

Doesn't that seem really, really painful to use in an interactive shell?
This is honestly (a simplified version of) what I tried in trying to learn
packaging.version.Version.  It was not a good experience:

% conda create -n test python=3.9 pandas
[...]
% conda activate test
% python
>>> import packaging
ModuleNotFoundError: No module named 'packaging'
^D
% pip install packaging
[...]
% python
>>> import packaging
>>> import panda, numpy, re,  statistics
>>> packaging.version.Version(pandas)
AttributeError: module 'packaging' has no attribute 'version'
>>> from packaging.version import Version
>>> Version(pandas)
TypeError: expected string or bytes-like object
>>> Version(pandas.__version__)

>>> Version(statistics.__version__)
AttributeError: module 'statistics' has no attribute '__version__'
>>> Version(re.__version__)

>>> import vaex
>>> Version(vaex.__version__)
TypeError: expected string or bytes-like object

I cannot find a case where the more verbose spelling is ever nicer than
just referencing `mod.__version__` directly for such exploration.  Yes, I
get that formal packaging has different needs.  But here it just seems like
a lot more work to get a lot less information back.

-- 
The dead increasingly dominate and strangle both the living and the
not-yet born.  Vampiric capital and undead corporate persons abuse
the lives and control the thoughts of homo faber. Ideas, once born,
become abortifacients against new conceptions.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/QW4ZCLPH3TMYQNZMFVVGXXRJDYAMOG75/
Code of Conduct: http://python.org/psf/codeofconduct/