[Python-Dev] Re: Documenting Python versioning and stability expectations

2021-10-16 Thread MRAB

On 2021-10-16 22:39, Oscar Benjamin wrote:

On Fri, 15 Oct 2021 at 14:12, Petr Viktorin  wrote:


Most of this is, hopefully, just capturing existing tribal knowledge, but:

[snip]


Micro Versions
--

A new micro version marks *bugfix* and *security* releases.
These releases are managed for stability; only fixes for known problems are
included in them, and Python's interfaces do not change in new micro
versions.

Generally, it is enough for third-party libraries to test with one
release of a minor version -- ideally the latest one.
For example, a library tested with Python 3.5.10 may reasonably claim to be
compatible with Python 3.5 in general.


I would just like to note that in SymPy we had problems a few times
because of changes made to typing in the 3.5.x series. The problem was
that CI tested the newest version of 3.5.x but many users were using
older versions and many features were added in micro releases e.g.
(random example from docs) typing.NoReturn has:

   New in version 3.5.4.
   New in version 3.6.2.

What that meant is that if a contributor had used NoReturn as a type
hint then because SymPy's CI only tested the most recent 3.5.x it
would not be noticed in PR review that SymPy had become unimportable
in 3.5.0.

This was not a major problem: where I saw complaints it seemed that
users were happy to upgrade to a newer Python 3.5.x. In general though
those changes do not match the explanation shown above. I welcome the
documentation around what kind of changes will be made in different
releases but just to be clear, should this preclude things like adding
typing.NoReturn in micro releases? (I hope so.)

Wasn't there a change in a micro version of Python 2? I can't remember 
the details, but from hindsight it was seen as a mistake that should not 
be repeated.

___
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/YEVSERPO4VJSHTP7YFVCS4HH7PQ3XLLD/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Packing a long list of numbers into memory

2021-10-10 Thread MRAB

On 2021-10-10 19:20, Gregory P. Smith wrote:



On Sun, Oct 10, 2021 at 7:25 AM Facundo Batista 
mailto:facundobati...@gmail.com>> wrote:


Hello everyone!

I need to pack a long list of numbers into shared memory, so I thought
about using `struct.pack_into`.

Its signature is

     struct.pack_into(format, buffer, offset, v1, v2, ...)

I have a long list of nums (several millions), ended up doing the
following:

     struct.pack_into(f'{len(nums)}Q', buf, 0, *nums)

However, passing all nums as `*args` is very inefficient [0]. So I
started wondering why we don't have something like:

     struct.pack_into(format, buffer, offset, values=values)

which would receive the list of values directly.

Is that because my particular case is very uncommon? Or maybe we *do*
want this but we don't have it yet? Or do we already have a better way
of doing this?

Thanks!

[0] https://linkode.org/#95ZZtVCIVtBbx72dURK7a4



My first reaction on seeing things like this is "Why not use a numpy.array?"

Does what you have really need to be a long list?  If so, that's already 
a huge amount of Python object storage as it is. Is it possible for your 
application to have kept that in a numpy array for the entirety of the 
data lifetime? 
https://numpy.org/doc/stable/reference/routines.array-creation.html 



I'm not saying the stdlib shouldn't have a better way to do this by not 
abusing *args as an API, just that other libraries solve the larger 
problem of data-memory-inefficiency in their own way already.


/(neat tricks from others regarding stdlib array, shm, & memoryview even 
if... not ideal)/


Maybe what's needed is to add, say, '*' to the format string to indicate 
that multiple values should come from an iterable, e.g.:


struct.pack_into(f'{len(nums)}*Q', buf, 0, nums)

in this case len(nums) from the nums argument.
___
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/6ZJ6B7ILRWH5BU4UAMNGOEJ5AIWRNFEJ/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: PEP 654 except* formatting

2021-10-05 Thread MRAB

On 2021-10-06 02:12, Barry Warsaw wrote:

What do the PEP authors think about `except group`?  Bikeshedding aside, that’s 
still the best alternative I’ve seen.  It’s unambiguous, self-descriptive, and 
can’t be confused with unpacking syntax.


+1
___
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/YHTK2JCUX4KZ6EDNYLAUEHXD2XNZTUDT/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: PEP 654 except* formatting

2021-10-04 Thread MRAB

On 2021-10-04 16:02, Jonathan Goble wrote:
On Mon, Oct 4, 2021 at 1:24 AM Guido van Rossum > wrote:


On Sun, Oct 3, 2021 at 9:20 PM Jonathan Goble mailto:jcgob...@gmail.com>> wrote:

Therefore my vote is for requiring `except* E` and keeping
`except *E` as a SyntaxError.


You can't do that with our current lexer+parser.


Then what is the purpose of this thread? I understood from the OP that 
the question was which to allow and which to prohibit. If it's 
impossible to require either or prohibit either because the lexer/parser 
can't tell the difference, then it's going to end up as a never-ending 
style argument just like C pointers, so what are we even discussing? 
(Other than an entirely different syntax, of course, which now seems 
like the logical way to go if we can't enforce a single way to do it 
with the original proposal.)
The key phrase is """in any case we need to settle on a convention that 

we use in documentation, 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/RYJTNZVMNF54XVUIE4MMN6TXS2XRPTXO/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: PEP 654 except* formatting

2021-10-04 Thread MRAB

On 2021-10-04 07:12, Greg Ewing wrote:

On 4/10/21 6:23 pm, Guido van Rossum wrote:
On Sun, Oct 3, 2021 at 9:20 PM Jonathan Goble > wrote:


Therefore my vote is for requiring `except* E` and keeping `except
*E` as a SyntaxError.

You can't do that with our current lexer+parser.


I don't think it would be desirable in any case. The separation of
tokens into alphanumeric and non-alphanumeric is deeply embedded in
every Python programmer's brain by now, and we shouldn't mess with
it.


It's not just a Python thing.
___
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/NTAXBGISW5CGLR2CWQ7HN4CCMDNF6OPG/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: PEP 654 except* formatting

2021-10-03 Thread MRAB

On 2021-10-03 18:50, Brandt Bucher wrote:

Łukasz Langa wrote:

My idea is this:
try:
...
except group E as e:
...
except group E1, T2 as e:
...
Should be doable given the magical match-case contextual keywords precedent. 
This looks nice and is explicit, since you will always get an ExceptionGroup 
instance under `e`.


Heh, we crossed posts with the soft keywords. I like your idea (“except group”) 
better than mine (“except each”).
If we want to use an existing keyword instead of a soft keyword, how 

about "except in E as e:".

The disadvantage, as I see it, from a linguistic point of view, is that 
"except in" could be read as "excluding", but, then, so could "except 
each" ("excluding each of these") and "except group" ("excluding this 
group").

___
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/FUTYE36MLFAWU72KTHDEQY5JFDA2PQ4G/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Worried about Python release schedule and lack of stable C-API

2021-09-25 Thread MRAB

On 2021-09-26 00:14, jack.jan...@cwi.nl wrote:
I’m getting increasingly worried about the future of Python, and those 
worries have been exacerbated by the new yearly release rhythm, and the 
lack of a stable C-API that is full enough to entice extension writers 
to use it.


PyPI packages and wheels are targeted to specific Python versions, which 
means that any project that depends on some of the larger extension 
packages (of which there are many, and many of which are must-have for 
many projects) now start lagging Python versions by years, because 
somewhere deep down in the dependency graph there is something that is 
still stuck at Python 3.8 (for example). I fully understand that 3.8 is 
good enough for the developers of that package, and that they have more 
pressing things to do than porting to 3.9 or 3.10, but it now keeps any 
project or package that depends on their software on 3.8 as well.


And I also fully understand that some other developer who creates a new 
package that is essential to my application only targets the current 
Python release, or maybe one release back, but now if I need both the 
new package and and older one I’m up the well-known creek without a paddle.


Building packages from source has become pretty much impossible 
nowadays, especially if your project is multi-platform and needs to 
interface to specific hardware, and you want to do the right thing with 
CI/CD builds and all that. On Linux/MacOS you have a chance when you try 
to specify all the dependencies for third party libraries and what not, 
but on Windows you’re dead in the water. And that is assuming you have 
the time and are smart enough to back port the new package to the old 
Python release, or the old package to the new Python release (and for 
the latter there’s probably a good reason why the developers haven’t 
done so already). Before you know it you have to install a couple of 
graphics card APIs for some obscure AI feature used by something you’ve 
never heard of, Cython for something else, and obscure vendor libraries 
for something else again.


I think we really need to come up with some scheme whereby extension 
packages become more long-lived than a single Python release...


You mean, something like the Python ABI (PEP 384, Stable Application 
Binary Interface)?

___
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/WFGX4ZRIRXQK4NZ6JSRZRQT7463FGFVG/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: PEP 467 feedback from the Steering Council

2021-09-08 Thread MRAB

On 2021-09-09 00:29, Rob Cliffe via Python-Dev wrote:



On 08/09/2021 21:21, Christopher Barker wrote:


[snip]
NOTE: my objection to “bchr”, whether as a builtin or not is not the 
functionality, it’s the name.



[snip]

Why not byte() ?

I happened to need to convert an integer to a byte recently and I settled on
      bytes((i,))
I don't know if I missed a more elegant solution (suggestions welcome),
but if I could write
      byte(i)
that would feel more Pythonic to me.


Well, I tend to see a byte as a value like an int.

If you slice a bytestring, you'd expect to get a bytestring, and you do.

If you subscript a bytestring, you expect to get a byte. You get an int, 
and that suggests that a byte is an int. (In Python 2 you got a 
bytestring, in Python 3 you get an int.)


The name could be misleading as byte(i) would return a bytestring, not a 
byte/int.

___
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/UU2QW6KV36H5RRFL6UG2REOFRWWXKCUK/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: PEP 467 feedback from the Steering Council

2021-09-08 Thread MRAB

On 2021-09-08 13:37, Victor Stinner wrote:

On Wed, Sep 8, 2021 at 7:46 AM Steven D'Aprano  wrote:

>>> bytes.from_int(121404708502361365413651784, 'little')
# should return b'Hello world'


Really? I don't know anyone serializing strings as a "bigint" number.
Did you already see such code pattern in the wild? Usually, bytes are
serialized as... bytes, no? Sometimes, bytes are serialized as base64
or hexadecimal to go through into an ASCII ("7-bit") bytestream. But I
don' recall any file format serializing bytes as a single large
decimal number.


Well, we already have int.from_bytes. What's that used for?

Adding the opposite conversion does make sense to me. If the number is 
0..255, and maybe the byteorder can be omitted in that case, then it 
seems like a reasonable solution to me.

___
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/MZGIU5ECYSAPVA47475ZEI4QQCQQJCYA/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: PEP 667: Consistent views of namespaces

2021-08-24 Thread MRAB

On 2021-08-24 17:55, Patrick Reader wrote:

On 24/08/2021 06:27, Steven D'Aprano wrote:

Wouldn't that attempt to resolve global y, rather than local y? Unless
there is a change to the current behaviour of the compiler, I think you 
need to fool the compiler:


   if False: y = 0  # anywhere inside the function is okay

Time to add a `nonnonlocal` statement ;)


Or perhaps use "not nonlocal"? :-)
___
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/USZ5FOQ6WF365VC7C4ZH4K4TR5AW2X2Q/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Problems with dict subclassing performance

2021-08-15 Thread MRAB

On 2021-08-15 22:50, Marco Sulla wrote:

On Sun, 15 Aug 2021 at 23:33, Tim Peters 
wrote:ople have said now, including me, they had no idea what

you meant.by "I pretend your immediate excuses". It's not a complaint
that it's expressed inelegantly, but that they can't make _any_ sense
of it. By my count, this is at least the second time you've declined
to explain what you meant, but instead implied the person who said
they couldn't understand it was being dishonest.


I repeat, even the worst AI will understand from the context what I
meant. But let me do a very rude example:


What if I said to Steven "I pretend immediate suck my $%#$"? Do you
think you and the others will not understand the sense? :D

C'Mon, you are offending my poor intelligence.

As I wanted to say, I pretend from Steven his excuses for his
insinuation, immediately. Is this clear now, or must I take an English
course at Cambridge?

I can figure it out, but I still find it very unclear and oddly phrased, 
and I'm a native English speaker of  years. And the sentence "I 
pretend from Steven his excuses for his insinuation, immediately" is 
just as odd.

___
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/XADHGFMPW274D4WN67JB5AUXVAURTQSR/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: New __main__.rst

2021-08-10 Thread MRAB

On 2021-08-10 03:14, Jack DeVries wrote:

There have been a series of requests to enhance the current __main__.rst
document :

bpo-17359 
bpo-24632 
bpo-39452 

So, I rewrote it! I went ahead and hosted it on my website for you all to
easily take a look: https://jackdevries.com/pydoc__main__/library/__main__.html

Of course, you can go directly to the GitHub PR instead:
https://github.com/python/cpython/pull/26883

For reference, here is a link to the current document:
https://docs.python.org/3/library/__main__.html

This is a major change, so I'm thankful for anyone who can take the time to
review it. I am a new cpython contributor, so advice for how to push this ahead
is also welcome. For example, should I break this up into multiple PRs at this
point?

Point of grammar: "Each of these mechanisms are related" should be "Each 
of these mechanisms is related". You might think that it's "are" because 
it follows "mechanisms", but it's "Each (something) is".

___
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/NRV2NHID465FGCMPHHLT7KS6WEOFSOU3/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: The repr of a sentinel

2021-05-23 Thread MRAB

On 2021-05-24 01:37, Luciano Ramalho wrote:

Sorry about my detour into the rejected idea of a factory function.

But how about this class-based API?

class NotGiven(Sentinel):
 pass


Now I can use NotGiven as the sentinel, and its default repr is .

The repr of other singletons are the names of those singletons, eg. 
"None", so why "" instead of "NotGiven"?



Behind the scenes we can have a SentinelMeta metaclass with all the
magic that could be required--including the default __repr__ method.


___
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/C672ZR7E6AD6KD5UVLUWD3GDQT66VACA/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: GDB not breaking at the right place

2021-05-23 Thread MRAB

On 2021-05-23 14:56, Skip Montanaro wrote:

I strongly suggest to only build Python with -O0 when using gdb. -Og
enables too many optimizations which makes gdb less usable.


Thanks, Victor. It never made sense to me that you would want any
optimizations enabled when truly debugging code (as opposed to wanting
debug symbols and a sane traceback in production code).

I'm getting more convinced that the problem I'm seeing is a GCC/GDB
thing, particularly because I can move the erroneous stopping point by
changing the GCC optimization level. I'll probably open a bugzilla
report just so it's on that team's radar screen. In the meantime, to
get going again I wrote a crude script which maps the
file:function:label form to file:linenumber form. That way I can
save/restore breakpoints across GDB sessions and still avoid problems
when the offsets to specific instructions change.

When I want to step through the regex module, I turn off optimisation, 
because any optimisation could move things around or combine things, 
making single-stepping difficult, and this is with Microsoft Visual Studio.


Just turn off optimisation when you want to single-step.
___
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/EWHXLCO4DKWGM3CZPZC2YFTNZPUSUSIY/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Future PEP: Include Fine Grained Error Locations in Tracebacks

2021-05-07 Thread MRAB

On 2021-05-08 01:43, Pablo Galindo Salgado wrote:
Some update on the numbers. We have made some draft implementation to 
corroborate the
numbers with some more realistic tests and seems that our original 
calculations were wrong.

The actual increase in size is quite bigger than previously advertised:

Using bytes object to encode the final object and marshalling that to 
disk (so using uint8_t) as the underlying

type:

BEFORE:

❯ ./python -m compileall -r 1000 Lib > /dev/null
❯ du -h Lib -c --max-depth=0
70M     Lib
70M     total

AFTER:
❯ ./python -m compileall -r 1000 Lib > /dev/null
❯ du -h Lib -c --max-depth=0
76M     Lib
76M     total

So that's an increase of 8.56 % over the original value. This is storing 
the start offset and end offset with no compression

whatsoever.


[snip]

I'm wondering if it's possible to compromise with one position that's 
not as complete but still gives a good hint:


For example:

  File "test.py", line 6, in lel
return 1 + foo(a,b,c=x['z']['x']['y']['z']['y'], d=e)
  ^

TypeError: 'NoneType' object is not subscriptable

That at least tells you which subscript raised the exception.


Another example:

  Traceback (most recent call last):
File "test.py", line 4, in 
  print(1 / x + 1 / y)
  ^
  ZeroDivisionError: division by zero

as distinct from:

  Traceback (most recent call last):
File "test.py", line 4, in 
  print(1 / x + 1 / y)
  ^
  ZeroDivisionError: division by zero
___
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/4RGQALI6T6HBNRDUUEYX4FA2YKTZDBNA/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Future PEP: Include Fine Grained Error Locations in Tracebacks

2021-05-07 Thread MRAB

On 2021-05-07 22:56, Larry Hastings wrote:

On 5/7/21 2:45 PM, Pablo Galindo Salgado wrote:
Given that column numbers are not very big compared with line numbers, 
we plan to store these as unsigned chars
or unsigned shorts. We ran some experiments over the standard library 
and we found that the overhead of all pyc files is:


* If we use shorts, the total overhead is ~3% (total size 28MB and the 
extra size is 0.88 MB).
* If we use chars. the total overhead is ~1.5% (total size 28 MB and 
the extra size is 0.44MB).


One of the disadvantages of using chars is that we can only report 
columns from 1 to 255 so if an error happens in a column
bigger than that then we would have to exclude it (and not show the 
highlighting) for that frame. Unsigned short will allow

the values to go from 0 to 65535.


Are lnotab entries required to be a fixed size?  If not:

if column < 255:
     lnotab.write_one_byte(column)
else:
     lnotab.write_one_byte(255)
     lnotab.write_two_bytes(column)


I might even write four bytes instead of two in the latter case,


A slight improvement would be:

if column < 255:
 lnotab.write_one_byte(column)
else:
 lnotab.write_one_byte(255)
 lnotab.write_two_bytes(column - 255)
___
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/UJYYDMXCM5TM7GOSIPMK7GOWNC25GL7W/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Future PEP: Include Fine Grained Error Locations in Tracebacks

2021-05-07 Thread MRAB

On 2021-05-07 22:45, Pablo Galindo Salgado wrote:

Hi there,

We are preparing a PEP and we would like to start some early discussion 
about one of the main aspects of the PEP.


The work we are preparing is to allow the interpreter to produce more 
fine-grained error messages, pointing to

the source associated to the instructions that are failing. For example:

Traceback (most recent call last):

   File "test.py", line 14, in 

 lel3(x)

 ^^^

   File "test.py", line 12, in lel3

 return lel2(x) / 23

    ^^^

   File "test.py", line 9, in lel2

 return 25 + lel(x) + lel(x)

 ^^

   File "test.py", line 6, in lel

 return 1 + foo(a,b,c=x['z']['x']['y']['z']['y'], d=e)

  ^

TypeError: 'NoneType' object is not subscriptable


The cost of this is having the start column number and end column number 
information for every bytecode instruction
and this is what we want to discuss (there is also some stack cost to 
re-raise exceptions but that's not a big problem in
any case). Given that column numbers are not very big compared with line 
numbers, we plan to store these as unsigned chars
or unsigned shorts. We ran some experiments over the standard library 
and we found that the overhead of all pyc files is:


* If we use shorts, the total overhead is ~3% (total size 28MB and the 
extra size is 0.88 MB).
* If we use chars. the total overhead is ~1.5% (total size 28 MB and the 
extra size is 0.44MB).


One of the disadvantages of using chars is that we can only report 
columns from 1 to 255 so if an error happens in a column
bigger than that then we would have to exclude it (and not show the 
highlighting) for that frame. Unsigned short will allow

the values to go from 0 to 65535.


[snip]How common are lines are longer than 255 characters, anyway?

One thought: could the stored column position not include the 
indentation? Would that help?

___
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/MHF3PMCJOR6VK765OSA7NSO66NY3QU3V/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: stdlib Flag Enums and the "no value" member

2021-04-29 Thread MRAB

On 2021-04-29 18:56, Ethan Furman wrote:

On 4/29/21 10:52 AM, Antoine Pitrou wrote:
  > On Thu, 29 Apr 2021 18:37:29 +0100, MRAB wrote:
  >> On 2021-04-29 18:19, Ethan Furman wrote:

  >>> An excerpt from bpo-31369: re.RegexFlag and `__all__`
  >>>
  >>> GvR:
  >>> 
  >>>> One thing I discovered when developing this example: there doesn't 
seem to be a flag to
  >>>> represent 0 (zero), i.e. "no flags".  And foo(0) is a type error 
(even though it works
  >>>> fine at runtime).
  >>>
  >>> Which raises the question:  Do we want to have a standard name for stdlib 
Flags when no flags are set?
  >>>
  >>> What should we call it?
  >>>
  >>> - NONE
  >>>
  >>> - ZERO
  >>>
  >>> - EMPTY
  >>>
  >>> - ???
  >>>
  >> Definitely NONE. At some point I might even add it to the regex module! :-)
  >
  > Not to confuse with None, which will not be equal to NONE.  Hmm...
  >
  > Perhaps NONE_SET or ALL_UNSET?
  >
  > (also, why the ALL_CAPS?)

Since Enum members are constants, ALL_CAPS is recommended for their naming 
scheme.


And the flags of the re module have always been ALL_CAPS.
___
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/DCKIHYXVZIRABF43M3NX75RZAXIQ3AOV/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: stdlib Flag Enums and the "no value" member

2021-04-29 Thread MRAB

On 2021-04-29 18:19, Ethan Furman wrote:

An excerpt from bpo-31369: re.RegexFlag and `__all__`

GvR:

  > One thing I discovered when developing this example: there doesn't seem to 
be a flag to
  > represent 0 (zero), i.e. "no flags".  And foo(0) is a type error (even 
though it works
  > fine at runtime).

Which raises the question:  Do we want to have a standard name for stdlib Flags 
when no flags are set?

What should we call it?

- NONE

- ZERO

- EMPTY

- ???


Definitely NONE. At some point I might even add it to the regex module! :-)
___
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/RBZ7ILB64FBFEHFQNHKGHJLYNUU3DMET/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: str() vs format(): trivia question

2021-04-20 Thread MRAB

On 2021-04-20 20:42, Ethan Furman wrote:

On 4/20/21 12:01 PM, Guido van Rossum wrote:
  > On Tue, Apr 20, 2021 at 11:12 AM Ethan Furman wrote:

  >> Moving forward, I'm not sure having format() and str() ever be different
  >> is a good idea, especially since users who need, for example, Color.RED
  >> to be '1' can simply add a `__str__ = int.__str__` to their own custom
  >> base IntEnum class and be good to go.  If we deprecate the current behavior
  >> now we could change it in 3.12.
  >>
  >> Thoughts?

  > So to be clear, that one user wants f"{Color.RED}" to return "1" and not
  > " Color.RED" (or  something like that). And you want f"{Color.RED}" and
  > str(Color.RED) to return the same value. Then together that means that
  > str(Color.RED) must also return "1".
  >
  > Did I get that right? And are you happy with that outcome?

Almost right. They should both return `Color.RED`.  Any users who want 
something different will need to do some work on
their end:

  class MyIntEnum(IntEnum):
  def __format__ = int.__format__

  class Color(MyIntEnum):
  RED = 1

  format(Color.RED)
  # '1'

The deprecation period will give that user, and others like them, time to add 
their own Enum base classes with the
`__format__` method they desire.


Couldn't the format accept 'd' if they want an int, i.e. f"{Color.RED:d}"?
___
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/IZH66WUEQJVEFBFBCOXXY3TMHJVLOEBF/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: PEP-376 and PEP-427 interpretation

2021-03-26 Thread MRAB

On 2021-03-27 01:54, Theallredman via Python-Dev wrote:
Forgive me if this isn't the correct venue for this question and I ask 
your help directing me to the correct place if it is not.


In PEP-376 it states with respect to the valid hashes in a Wheel RECORD 
file:


"The hash is either the empty string or the hash algorithm as named in 
hashlib.algorithms_guaranteed, followed by the equals character =, 
followed by the urlsafe-base64-nopad encoding of the digest 
(base64.urlsafe_b64encode(digest) with trailing = removed)."


In PEP-427 it further restricts the valid hashes to omit md5 and sha1 
and says:


"The hash algorithm must be sha256 or better; specifically, md5 and sha1 
are not permitted."


No where does it define what on what dimension of a hash "better" should 
consider.  From the context talking about the security of the algorithm 
I'd infer that "better" is with respect to collision resistance.  If so 
does that mean sha224 should also be excluded from wheel RECORD file hashes?


The "256" part refers to it generating a 256-bit signature, so a 
"better" one is one that generates a signature that's longer, e.g. 
"sha384" and "sha512".

___
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/6RAUURQDHYGQEFNNEZTIEOJ2J3BUMN5B/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Non-monotonically increasing line numbers in dis.findlinestarts() output

2021-03-17 Thread MRAB

On 2021-03-17 22:10, Skip Montanaro wrote:

Consider this little session from the tip of the spear:

 >>> sys.version
'3.10.0a6+ (heads/master:0ab152c6b5, Mar 15 2021, 17:24:38) [GCC 10.2.0]'
 >>> def while2(a):
...     while a >= 0:
...         a -= 1
...     return a
...
 >>> dis.dis(while2)
   2           0 LOAD_FAST                0 (a)
               2 LOAD_CONST               1 (0)
               4 COMPARE_OP               5 (>=)
               6 POP_JUMP_IF_FALSE       24

   3     >>    8 LOAD_FAST                0 (a)
              10 LOAD_CONST               2 (1)
              12 INPLACE_SUBTRACT
              14 STORE_FAST               0 (a)

   2          16 LOAD_FAST                0 (a)
              18 LOAD_CONST               1 (0)
              20 COMPARE_OP               5 (>=)
              22 POP_JUMP_IF_TRUE         8

   4     >>   24 LOAD_FAST                0 (a)
              26 RETURN_VALUE
 >>> list(dis.findlinestarts(while2.__code__))
[(0, 2), (8, 3), (16, 2), (24, 4)]

I get that somewhere along the way the compiler has been optimized to 
duplicate the loop's testso as to eliminate some jumps (perhaps). It's 
not clear to me that the line number should be "2" in the duplicated 
test though.Shouldn't it be "3"?


The condition is on line 2. The fact that it has been duplicated n the 
bytecode is irrelevant; it's still on line 2 in the source.


Line 3 has the decrement and line 4 has the return.

I stumbled on this while trying to generate a line number table in my 
side project register VM. As I understand it, the line number delta in 
the output table is supposed to always be >= 0. In my code I'm using 
dis.findlinestarts() to determine the line numbers for each block. 
Perhaps I should be modifying its results. OTOH, maybe it's a bug. (If 
that's the consensus, I will create an issue.)



___
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/X52UUKO22IHCKCW7N6GNBFAHBRZTMMMO/
Code of Conduct: http://python.org/psf/codeofconduct/


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

2021-03-10 Thread MRAB

On 2021-03-10 15:17, Antoine Pitrou wrote:

On Wed, 10 Mar 2021 14:23:33 +
David Mertz  wrote:


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.


Uh... Since you're putting "fun" in quotes, I assume this is quoting
someone else? (who?)

It's not a quote, it's Irony punctuation (in this case, used to indicate 
sarcasm):


https://en.wikipedia.org/wiki/Irony_punctuation
___
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/RJUCHSTSFC6IJPILRPYFQYY437NEOQ4G/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

2021-02-23 Thread MRAB

On 2021-02-23 23:05, Caleb Donovick wrote:
What is the motivation for returning `None` on empty splits?  I feel 
like this creates an unnecessary asymmetry.  I don't personally have a 
use case for the this feature so I may be missing something but it seems 
like it would force an annoying pattern:


```
try:
     foo()
except ExceptionGroup as eg:
     g1, g2 = eg.split(predicate)
     for e in g1:
         handle_true(e)
     for e in g2:
         handle_false(e)
```
Would need to be written:
```
try:
     foo()
except ExceptionGroup as eg:
     g1, g2 = eg.split(predicate)
     if g1 is not None:
         for e in g1:
             handle_true(e)
     if g2 is not None:
         for e in g2:
             handle_false(e)
```

Also this creates an subtle difference with subgroup:

```
g1, g2 = eg.split(predicate)
h1, h2  = eg.subgroup(predicate), eg.subgroup(lambda e: not predicate(e))
assert g1 == h1 and g2 == h2 # only true if `None not in {g1, g2}`
```


.subgroup returns an ExceptionGroup and .split returns 2 of them.

ExceptionGroup isn't iterable (it's mentioned in the "Rejected Ideas" 
section), so your code wouldn't work anyway.


On Mon, Feb 22, 2021 at 4:47 PM Irit Katriel via Python-Dev 
mailto:python-dev@python.org>> wrote:



Hi all,

We would like to request feedback on PEP 654 -- Exception Groups and
except*.

https://www.python.org/dev/peps/pep-0654/


It proposes language extensions that allow programs to raise and
handle multiple unrelated
exceptions simultaneously, motivated by the needs of asyncio and
other concurrency libraries,
but with other use cases as well.

* A new standard exception type, ExceptionGroup, to represent
multiple exceptions with
   shared traceback.
* Updates to the traceback printing code to display (possibly
nested) ExceptionGroups.
* A new syntax except* for handling ExceptionGroups.

A reference implementation (unreviewed) can be found at:
https://github.com/iritkatriel/cpython/pull/10


Thank you for your help


___
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/U7A4PZE7SSDFNKAFZZ3BZBLL7VGTOWVL/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Why aren't we allowing the use of C11?

2021-01-28 Thread MRAB

On 2021-01-28 19:20, Terry Reedy wrote:


On 1/28/2021 11:26 AM, Mark Shannon wrote:


PEP 7 says that C code should conform to C89 with a subset of C99 allowed.


As I remember, when the Python C dialect was discussed about 4 years
ago, no one seriously proposed moving beyond a subset of C99 addition,
because of the state of MSVC.

It's 2021 and all the major compilers support C11 (ignoring the optional 
parts).


C11 has support for thread locals, static asserts, and anonymous structs 
and unions. All useful features.


Is there a good reason not to start using C11 now?


Inertia is *a* reason.  C11 would require (and allow!) most (nearly
all?) people compiling CPython on Windows to upgrade their VS-VC setup.
   Maybe including some buildbot machines.

Judging from the post for
https://bugs.python.org/issue42380
this requires VS 16.8 with MSVC 14.28, released last November.  Prior
distributions of VS 2019 had earlier versions.  Last I knew, regular
people without a dev license cannot get just MSVC.  So we cannot require
a compiler most people cannot get.  This post otherwise gives additional
reasons why upgrading would be good.


[snip]

I have Microsoft Visual Studio Community 2019 Version 16.8.4 (it's free) 
and it supports C11 and C17.

___
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/OHYLWZ6GTHPFI3FH7OEMXAHCSW5PVRNA/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Enhancement request for PyUnicode proxies

2020-12-27 Thread MRAB

On 2020-12-27 19:15, Guido van Rossum wrote:
On Sun, Dec 27, 2020 at 3:19 AM Ronald Oussoren > wrote:





On 26 Dec 2020, at 18:43, Guido van Rossum mailto:gu...@python.org>> wrote:

On Sat, Dec 26, 2020 at 3:54 AM Phil Thompson via Python-Dev
mailto:python-dev@python.org>> wrote:

It's worth comparing the situation with byte arrays. There is
no problem
of translating different representations of an element, but
there is
still the issue of who owns the memory. The Python buffer
protocol
usually solves this problem, so something similar for unicode
"arrays"
might suffice.


Exactly my thought on the matter. I have no doubt that between all
of us we could design a decent protocol.

The practical problem would be to convince enough people that this
is worth doing to actually get the code changed (str being one of
the most popular data types traveling across C API boundaries), in
the CPython core (which surely has a lot of places to modify) as
well as in the vast collection of affected 3rd party modules. Like
many migrations it's an endless slog for the developers involved,
and in open source it's hard to assign resources for such a project.


That’s a problem indeed.  An 80% solution could be reached by
teaching PyArg_Parse* about the new protocol, it already uses the
buffer protocol for bytes-like objects and could be thought about a
variant of the protocol for strings.  That would require that the
implementation of that new variant returns a pointer in the Py_view
that can used after the view is released, but that’s already a
restriction for the use of new style buffers in the PyArg_Parse* APIs.

That wouldn’t be a solution for code using the PyUnicode_* APIs of
course, nor Python code explicitly checking for the str type.

In the end a new string “kind” (next to the 1, 2 and 4 byte
variants) where callbacks are used to provide data might be the most
pragmatic.  That will still break code peaking directly in the the
PyUnicodeObject struct, but anyone doing that should know that that
is not a stable API.


That's an attractive idea. I've personally never had to peek inside the 
implementation, and I suspect there's not that much code that does so 
(even in the CPython code base itself, outside the PyUnicode 
implementation of course).



The re module does it extensively for speed reasons.
___
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/4LUBFUFQL6TNIX6CGTTF3O5M6IFXOME3/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Advice / RTFM needed for tool setup to participate in python development from a Windows host

2020-12-16 Thread MRAB

On 2020-12-16 19:19, Paul Moore wrote:

Personally, I just have Visual Studio and VS Code as my text editor. I
rarely use Visual Studio directly, though, I mostly use the
`build.bat` and similar scripts in the `PCBuild` directory.

Having said that, I'm not doing anything like debugging problems with
DLLs, for which I imagine a decent C development environment is
needed. You don't have much choice other than Visual Studio there (no
other compiler is supported on Windows), though, so you'll probably
need to learn that.

Paul


FWIW, I debug the regex module in Visual Studio 2019 Community.

I compile a release build with optimisations turned off when I'm going 
to be single-stepping through the code, otherwise it's very confusing 
with it jumping around all over the place due to the optimisations it's 
done.



On Wed, 16 Dec 2020 at 18:28,  wrote:


Hello,

I hope this is the correct place to ask this question.  I have a desire to
participate in python development in a particular area from my Windows host
machine, but I am not finding any concise listing of the tool setup needed
to fully participate, nor any detailed guidance on how to proceed when
underlying code debugging is necessary.

I do know that some version of the MS VS20xx suite is necessary to begin.
My initial attempts using the VS2019 Community Edition have been less than
successful when it comes to debugging an underlying C library component when
the starting program is python because I have not figured out how to use the
VS2019 environment to do that.

So I would appreciate any RTFM / URL that can guide me in starting to
participate, especially for guidance on debugging procedures for underlying
C components when the initial program is a python script.

I have read most of the "Python Developers Guide" material, but there is not
any Window-specific tooling information that I have seen there yet.  What
other tooling do I need besides a VS20xx environment?

I do have good experience in C programming, but not much in using VS20xx
IDE's.

TIA for your gentle guidance in curing my ignorance.

Peter


___
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/G3TMEOP6NCQCP63WT4OP4O4HFZNEUUQB/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Why does "except Ex as x" not restore the previous value of x?

2020-11-17 Thread MRAB

On 2020-11-18 03:36, Larry Hastings wrote:



[snip]
But then we get to generator expressions and list/dict/set 
comprehensions.  I think of those as doing an "assignment", but I have 
to remember the assignment "doesn't leak":


x = 3
y = list(x**2 for x in range(5))
print(f"{x=}")

This code prints "x=3".

Why this exception to the rule?  IIRC from the discussions back when 
they were added, this one of those "it just seemed best at the time" 
things.  "for" was added to the language long before I got there, but it 
"leaking" its assignment was judged useful; if you broke out of the 
loop, you could continue to examine the last value from the loop.  But, 
the thinking went, you'd never want to examine the last value from a 
list generator, so it was more convenient if it behaved as if it had its 
own scope.



[snip]
I think the reason that generator expressions don't leak is that 
experience of list comprehensions, which did leak, showed that it was a 
bad idea. List comprehensions were "fixed" in Python 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/Y7S6VWQOVWICPBDUE7MS7RHGA67AQULO/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: PEP 642 v2: Explicit constraint patterns *without* question marks in the syntax

2020-11-16 Thread MRAB

On 2020-11-16 08:54, Glenn Linderman wrote:

On 11/15/2020 11:18 PM, Stephen J. Turnbull wrote:

Jim J. Jewett writes:

  > What advantage can there be in re-using syntax to mean something
  > opposite to what it normally does?

In math, it allows us to write "solve c = f(x) for x".  That doesn't
mean "bind c to the value f(x)", it means exactly the opposite.  No
problem here, I suppose.  So

 match p:
 case Point(x=a, y=b):

is a way of saying "solve p = Point(x=a, y=b) for a and b".

I understand your distaste for this syntax, but I see no problem
in principle.  It's a problem of programmer habits and the evident
inconsistency with forms like "case Point(x=1, y=2)".  This is
especially true when a or b is already bound.

Indeed. Mathematics never came up with separate symbols for equality and
assignment. Neither did early programming languages. That was a source
of confusion for many programmers.


[snip]

Fortran (1954) used '=' for assignment and '.EQ.' for equality.

Algol (1958) used ':=' for assignment and '=' for equality.
___
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/TGONBSN7ZEVNNGMC5HZMK3BASLGHVILX/
Code of Conduct: http://python.org/psf/codeofconduct/


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

2020-11-15 Thread MRAB

On 2020-11-15 09:48, 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.



That looks like a mistake to me; it should be "complementary".

[snip]
___
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/FL5VVQGGF4KQ6VCMGVFF6BM4BGCDGFKT/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: PEP 642 v2: Explicit constraint patterns *without* question marks in the syntax

2020-11-12 Thread MRAB

On 2020-11-12 19:21, Paul Sokolovsky wrote:

Hello,

[Re-routed back to python-dev.]

On Thu, 12 Nov 2020 20:04:57 +0100
Piotr Duda  wrote:

[]


> match foo:
> case ("foo", >val1):
> ...
> case ("bar", >val2):
> ...
>  


I agree with that, though I would prefer using other symbol than > (?
or $), one of reasons would by it would look better as "match all"
target, other one that in future. it would allow extending syntax for
simple guards like ?x < 100.


Question of "what to mark with sigils - terms-used-as-values or
terms-used-for-capturing" is orthogonal to the question of "what to use
as match-all symbol", though I understand the desire to repurpose the
same symbol for both.

For a capturing sigil, "->", ">", ">>", "@", "?", "$" already were or
can be proposed. The benefit of "->", ">", ">>" is that they're very
intuitive. I'd also have preference for shorter one, because 2-chars
are really verbose IMHO. OTOH, ">" has issue with parsing ambiguity
unless separated by spaces ("Cls(kw1=>var)"). "$" is the worst choice
IMHO, because intuitively (based on other languages - shell, etc.) it
says "use the value of variable".

I'd still want to list "as" as another possibility, the advantage being 
that it's already used for binding elsewhere.



That said, those are 2nd-level choices. The current stage is to accept
the fact that "mark capturing terms" is *very viable* alternative to
"mark terms to use as values" (3rd choices - "use adhoc interpretation
of non-orthogonal syntactic conventions" - being the worst). But people
behind PEPs keep ignoring that choice - silently, or with minimal
consideration/commentary.


___
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/I6RUS35XIWQRD5RFSWSBEVBUG7VONVQZ/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Pattern matching reborn: PEP 622 is dead, long live PEP 634, 635, 636

2020-10-22 Thread MRAB

On 2020-10-22 17:48, Guido van Rossum wrote:
After the pattern matching discussion died out, we discussed it with the 
Steering Council. Our discussion ended fairly positive, but there were a 
lot of problems with the text. We decided to abandon the old PEP 622 and 
break it up into three parts:


- PEP 634: Specification
- PEP 635: Motivation and Rationale
- PEP 636: Tutorial

This turned out to be more work than I had expected (basically we wrote 
all new material) but we've finally made it to a point where we can 
request feedback and submit the new version to the SC for approval.


While the text of the proposal is completely different, there aren't 
that many substantial changes:


- We changed walrus patterns ('v := p') to AS patterns ('p as v').
- We changed the method of comparison for literals None, False, True to 
use 'is' instead of '=='.

- SyntaxError if an irrefutable case[1] is followed by another case block.
- SyntaxError if an irrefutable pattern[1] occurs on the left of '|', 
e.g. 'x | [x]'.


Is "syntax error" that the right term for it? Maybe it should be 
something different, a subclass of SyntaxError perhaps.


[snip]
___
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/JHX6WDK3GMJD6ALXWEJ3K45WOXQUKZQW/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

2020-08-03 Thread MRAB

On 2020-08-03 05:21, Guido van Rossum wrote:
Your point about wanting a way to use an unqualified name as a value 
pattern is not unreasonable, and as you may recall we had an elegant 
solution in version 1 of the PEP: a leading dot. However that was booed 
away by the critics, and there has been no consensus (not even close) on 
what to do instead.


Any solution that involves special markup (like bringing back the 
leading dot, or backticks, or a question mark, or any other sigil) can 
easily be added in a future version of Python.


There is one solution that I personally find acceptable but which found 
little support from the other PEP authors. It is a rule also adopted by 
Scala. This is to make it so that any identifier starting with a capital 
letter (possibly preceded by one or more underscores) is a value 
pattern. I note that in Scala, too, this is different in patterns than 
elsewhere in the language: Scala, like Python, allows identifiers 
starting with a capital letter to be assigned in other contexts -- just 
not in patterns. It also uses roughly the same *conventions* for naming 
things as PEP 8 (classes Capitalized, constants UPPERCASE, variables and 
methods lowercase). I also note that Scala allows backticks as another 
way to force interpretation as a value pattern (though apparently it's 
not used much for this purpose).



[snip]
A thought occurred to me. By default, the current rules of the PEP could 
apply, but why not allow prefixing with "as" for a capture and "is" for 
a value?


Yes, I know, comparison of the values is not by identity, but "is" is a 
short keyword that already exists and matches up with "as".



(After looking back through the thread it looks like Rob Cliffe has 
already had the same idea.)

___
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/XVAJ76OOVFT3RJXDJH3BRNEHOFS7PAJS/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: How to customize CPython to a minimal set

2020-07-21 Thread MRAB

On 2020-07-21 06:33, Huang, Yang wrote:

Hi, Guido

Yes. Micropyhton is also in consideration.

But sqlite3 is the first usage. There should be some additional features 
like numpy, scipy... Not sure if micropython supports well?


Or is there a feasible way to strip CPython ?

Thanks.


You want a minimal Python, yet with numpy, scipy, ...? Those sound like 
contradictory goals to me!




*From:* Guido van Rossum 
*Sent:* Monday, July 20, 2020 10:45 PM
*To:* Huang, Yang 
*Cc:* python-dev@python.org
*Subject:* Re: [Python-Dev] How to customize CPython to a minimal set

Have you considered starting with micropython? It’s made for embedded 
systems and fully supports Python 3 syntax. Adding sqlite3 support to it 
will be less work than stripping all the I/O from CPython.


—Guido

On Mon, Jul 20, 2020 at 06:48 Huang, Yang > wrote:



Hi, all

There is a request to run python in a Linux-based embedded resource
constrained system with sqlite3 support.

So many features are not required, like posixmodule, signalmodule,
hashtable ...
But seems there are some dependencies among the
Modules/Parser/Python/Objects/Programs...

Is there a way to tailor CPython 3 to a minimal set with sqlite3
(the less syscalls the better) ?
Is it possible to do that?

Thank you.


___
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/GITUFJA4FQNVBTD2MMGV46JDGPDPLKOJ/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

2020-07-16 Thread MRAB

On 2020-07-16 19:05, Richard Damon wrote:

On Jul 16, 2020, at 1:36 PM, Chris Angelico  wrote:

On Fri, Jul 17, 2020 at 3:25 AM Federico Salerno  wrote:

Tools should adapt to the language, not the other way around. If things had to 
be done the way they had always been done, without any change, for fear of 
people not being used to it, we wouldn't even have Python at all. People learn 
and adapt. It seems like a small price to pay in exchange for consistency and 
removal of ambiguity, considering people will still have to learn the new 
feature one way or another.



But consistency is exactly what you'd be destroying here. Python is
extremely consistent in that you ALWAYS indent after a line ends with
a colon, and what comes after it is logically contained within that
statement. It's about whether *people* can handle it, more than
whether tools can, and the consistency helps a lot with that.

ChrisA


One question that comes to mind, does match NEED a colon at the end of it? If 
it didn’t have the colon, it wouldn’t need the indent for the following lines.


All of the others have the colon.
___
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/Z63GPE46RPULXJRIFVOBF4DDM3BCKD5B/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

2020-07-16 Thread MRAB

On 2020-07-16 17:37, Steve Holden wrote:
While I understand the point of view that says that match ... : 
should encapsulate a sequence of indented suites, it seems to me that 
match/case/case/.../else has a natural affinity with 
try/except/except/.../finally/else, and nobody seems to think that the 
excepts should be indented. Or the finally. And naturally the match/else 
case are at the same indentation level, just as for/else, while/else and 
try/finally. So why, exactly, should case be indented?


My apologies for being a Bear of Very Little Brain.


[snip]
For all other statement structures (if, while, try, etc.), the first 
line ends with a colon and the second line is indented (and is a 
statement). Therefore the cases should be indented.


However, for all other statement structures (if, while, try, etc.), the 
other parts of the structure itself (elif, else, except, etc.) aren't 
indented. Therefore the cases shouldn't be indented.


Either way, it's inelegant.
___
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/4W2J5SLLOTLPMMFIZ4KTAC4THJMDCWBW/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

2020-07-12 Thread MRAB

On 2020-07-12 23:20, Guido van Rossum wrote:
[snip]
The need for a wildcard pattern has already been explained -- we really 
want to disallow `Point(x, y, y)` but we really need to allow `Point(z, 
_, _)`. Generating code to assign the value to `_` seems odd given the 
clear intent to *ignore* the value.


Using `?` as the wildcard has mostly disadvantages: it requires changes 
to the tokenizer, it could conflict with other future uses of `?` (it's 
been proposed for type annotations as a shorter version of Optional, and 
there's PEP 505, which I think isn't quite dead yet), and Python users 
have no pre-existing intuition for its meaning.


FWIW, I don't think this use of '?' would conflict with the other 
suggested uses because this use would be initial in an expression, 
whereas the other uses would be non-initial.


[snip]
___
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/D33YT2KBNVZS27JJIYA5BDWPIP5IWB7M/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

2020-07-11 Thread MRAB

On 2020-07-12 01:32, Chris Angelico wrote:

On Sun, Jul 12, 2020 at 10:30 AM Greg Ewing  wrote:


Just had another thought about marking assignment targets.

The PEP currently forbids repeating bound names in a pattern
to avoid raising expectations that

 case Point(x, x):

would match only if the two arguments were equal.

But if assignment targets were marked, we could write this as

 case Point(?x, x):

and it would work as expected.



Hang on. Matching happens before assignment, so this should use the
previous value of x for the matching. At least, that's my
understanding. If you do something like:

case Point(x, 2):

it won't assign x unless the second coordinate is 2, right?

Presumably the assumption is that it would use a local dict for binding, 
faling back to the actual dict if necessary for lookup, and then update 
the actual dict if the match is successful. That way, unsuccessful 
matches won't pollute the actual dict.

___
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/OUT2EZB5VMWT4VGJCGF7DAWMTNJAVHRT/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

2020-07-11 Thread MRAB

On 2020-07-11 20:56, Steve Holden wrote:
Given that case will be a keyword, what's the case (pun unintentional) 
for indenting the case clauses? What's wrong with 'case' and 'else' both 
indented the same as match? Without the keyword there'd be a case for 
indenting, but with it I don't see the necessity.


Kind regards,
Steve


The issue is as follows.

In Python, the style is that multi-line statements start with a keyword 
and that logical line ends with a colon. The next line is a statement, 
which is indented. The other parts of the statement structure are 
indented the same amount as its first line:


if ...:
...
elif ...:
...
else:
...

The 'match' statement (or a 'switch' statement), however, can't follow 
the existing style.


It's either:

match ...:
case ...:
case ...:

where the second line isn't indented (unlike all other structures), or:

match ...:
case ...:
case ...:

where the other parts of the structure (the cases) aren't indented the 
same as the first line.


Another possibility is:

match:
...
case ...:
case ...:

but the second line is an expression, not a statement (unlike all other 
structures).


An alternative is:

match ...
case ...:
case ...:

no colon ending the first line, and no indenting of the second line, but 
that's unlike  all other structures too.


None of the possibilities are formatted like the existing style.

So it's a case of picking the least inelegant one.



On Fri, Jul 10, 2020 at 12:09 PM Greg Ewing > wrote:


A thought about the indentation level of a speculated "else" clause...

Some people have argued that "else" should be at the outer level,
because that's the way it is in all the existing compound statements.

However, in those statements, all the actual code belonging to the
statement is indented to the same level:

      if a:
          
      elif b:
          
      else:
          

          ^
          |
          Code all indented to this level

But if we were to indent "else" to the same level as "match",
the code under it would be at a different level from the rest.

      match a:
          case 1:
              
          case 2:
              
      else:
          
          ^   ^
          |   |
          Code indented to two different levels

This doesn't seem right to me, because all of the cases, including
the else, are on the same footing semantically, just as they are in
an "if" statement.


___
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/M4YMCRVSKVKNUXQFI5KOMT5MQH6WJ23O/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: PEP 622: Structural Pattern Matching -- followup

2020-07-08 Thread MRAB

On 2020-07-08 03:08, Rob Cliffe via Python-Dev wrote:

Why not use '=' to distinguish binding from equality testing:
      case Point(x, =y): # matches a Point() with 2nd parameter equal to
y; if it does, binds to x.

This would allow a future (or present!) extension to other relative
operators:
      case Point(x, >y):
(although the syntax doesn't AFAICS naturally extend to specifying a
range, i.e. an upper and lower bound, which might be a desirable thing
to do.
Perhaps someone can think of a way of doing it).

Whether
      case =42:
      case 42:
would both be allowed would be one issue to be decided.

In Python, '=' is assignment and '==' is equality. Using '=' for 
equality could lead to confusion.

___
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/KYUZQRZNDOVFEOC5XBYOFXKTPK7LAZI4/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: PEP 622 railroaded through?

2020-07-07 Thread MRAB

On 2020-07-08 02:20, Greg Ewing wrote:

On 8/07/20 12:48 pm, Chris Angelico wrote:

"for x[0] in iter:" uses
x[0] as an assignment target,


You're right, there are some others, but I think they're
equally clear -- all the ones I can think of are directly
after a keyword ("for", "as", "import", etc.)

But in match statements, they can be arbitrarily
intermingled with other expression-like stuff.


You're right about the presence/absence of a dot being very subtle,
but hang tight, wait for the next publication of the PEP; its authors
are working on that exact problem.


It looks like the only thing they're doing is dropping
the *leading* dot case -- without providing any replacement
for it. That only addresses one small part of my concern,
since I think the non-leading dot is nearly as subtle.
Maybe even more so, since at least the leading dot was
obviously something different.

Also I don't like the idea of being *forced* to use
a namespace for my constants, regardless of how good an
idea the PEP authors think it is.

Prefixing values with "==" might be the clearest, an idea that, I think, 
Ethan came up with. It might not look elegant, but...

___
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/UXPHME2CTQ3KMBA3QC2ZXPHDHWZAMEBS/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: [Python-ideas] Re: Amend PEP-8 to require clear, understandable comments instead of Strunk & White Standard English comments

2020-07-04 Thread MRAB

On 2020-07-04 21:07, Martin Dengler wrote:

On Sat, Jul 04, 2020 at 05:51:04PM +0100, MRAB wrote:
>I'd also add: Try to avoid regionalisms; aim for a 
>broadly "international" form of the language. Some 


How do you spell "regionalism"?

Martin

PS: Irony intended


As far as I'm aware, there's only one way to spell it, but I'm sure 
someone can phrase it better.


___
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/7A4AWOEAWU4ZZBPSJ67C5BP3BYA6RRZG/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Recent PEP-8 change

2020-07-04 Thread MRAB



On 2020-07-04 19:23, Paul Moore wrote:

On Sat, 4 Jul 2020 at 17:48, MRAB  wrote:
>
> On 2020-07-04 05:51, Greg Ewing wrote:
> > On 4/07/20 4:33 am, Jim J. Jewett wrote:
> >> If Bob and Alice seem neutral to you, would you do a double-take on 
Kehinde or Oladotun?
> >
> > Maybe we should use randomly generated names for hypothetical persons?
> >
> Ideally they should be short names, one or two syllables.

Surely the obvious thing to do would be to use Monty Python characters?

True, but if they were all called Eric it could be confusing.
___
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/ZYK5PHZUYA2PUVWJSZUS52R6AOJLPS7L/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: [Python-ideas] Re: Amend PEP-8 to require clear, understandable comments instead of Strunk & White Standard English comments

2020-07-04 Thread MRAB

On 2020-07-04 16:23, Stephen J. Turnbull wrote:

@Inada-sama: For RFC conformance to S, see footnote [3] at the end.

MRAB writes:

  > If you believe you have something important to say, then at least
  > say it clearly.

Indeed -- that commit log is an example of the kind of writing the
reference to Strunk & White was intended to reduce; repetitive,
jargon-filled, and mostly unnecessary to make the point.[1]  Ironic,
but not the only irony to be found in this commit.

Because I have seen the deterrent effect in action -- *it is real* --
I'd be sympathetic to this change if I hadn't directly experienced the
value of a rule set like that in Strunk & White in teaching non-native
speakers about writing English for technical purposes.  Since I
believe an admonition to "write clear and easily understandable
English" is a deterrent too, especially for non-natives, I would
prefer deleting the whole thing to this change, though.

The claim is that requiring Strunk & White deters PoC.  I believe it.
But by discarding all rules, this change "centers" English-speakers at
the expense of the needs of large populations of *non-native-speaking*
PoC.  Many non-natives would benefit from adopting some of the advice
in Strunk & White for *writing* clearly, and if others follow that
advice, it would easier for them to *read*.[2]  Don't take my word for
it: Naoki Inada testifies to both issues in his post about "RFC
English".[3]

It has also been claimed that many neuro-atypical folks find detailed
rules comforting, as opposed to broad admonitions of that kind.  Seems
plausible, but I can't speak to it from personal experience or
testimony of acquaintances.  But if so, removing all reference to
concrete rules for clear writing harms and deters them, too.

But "practice what you preach" is a fallacy, I guess.  "Do what I say,
not what I do" is the way of the world.  Given human fallibility,
maybe this is a not-bad thing, to focus on the merits of folks' speech
rather than the demerits of their actions *shrug*

As I see it, in order of importance, we could say the following about
comments in Python:

1.  Comments should not say anything that a programmer with some
 experience can read directly from the code, taken out of the
 larger context.  That eliminates a lot of problematic text right
 off the bat! :-)

2.  Write comments in English.  It is the lingua franca [sic!] of
 programming, for better or worse, and Python development is an
 international community of programmers.  (The language may change,
 see "sic!" above.  Boy, would I enjoy watching some folks struggle
 with Hindi or Chinese.)

3.  Write in a comfortable dialect[4].  (Exceptions: legalese and
 The Academic Register are strictly forbidden, even if you're
 native in one of those. :-)
I'd also add: Try to avoid regionalisms; aim for a broadly 
"international" form of the language. Some words and phrases might be 
specific to a certain region, or have different, possibly conflicting, 
meanings elsewhere.

4.  Write clear and easily understandable comments, remembering that
 many potential readers are not native speakers, let alone native
 in "Standard" English.

5.  For advice on writing clearly, Zinsser is a good textbook on
 writing to communicate.  Strunk & White is a concise collection of
 concrete rules with examples of usage that help many to write more
 clearly, and its table of contents serves as a somewhat Petersian
 "Zen of Technical Writing".  (There may be better alternatives to
 both for those purposes, but I don't know of any.)

[snip]

___
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/HOLPBECIPKDDIXZEISB7VLJIUUPGD7O3/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Recent PEP-8 change

2020-07-04 Thread MRAB

On 2020-07-04 05:51, Greg Ewing wrote:

On 4/07/20 4:33 am, Jim J. Jewett wrote:

If Bob and Alice seem neutral to you, would you do a double-take on Kehinde or 
Oladotun?


Maybe we should use randomly generated names for hypothetical persons?


Ideally they should be short names, one or two syllables.
___
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/HTCYNHWLGHPLN6L45VUQKNCYJT4GCW3Y/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Recent PEP-8 change (Antoine Pitrou)

2020-07-03 Thread MRAB

On 2020-07-03 17:52, Jim J. Jewett wrote:

Specifying British English (as opposed to just British spelling) would probably 
tempt people to use more Brit-only idioms, in the same way that Monty Python 
tempts people to make Flying Circus references.

I don't love the idea of talking more about how many zeroes in a billion, or whether 
"table it" is an extra-fun reference *because* of the ambiguity.


The UK officially switched to the "short" billion (9 zeros) in 1974.

See: https://en.wikipedia.org/wiki/Billion
___
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/PEFPBAMWAFW4VVZAKSD2O2PDJ6OEZH7B/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: [Python-ideas] Re: Amend PEP-8 to require clear, understandable comments instead of Strunk & White Standard English comments

2020-07-02 Thread MRAB

On 2020-07-02 22:17, Jeff Allen wrote:

On 01/07/2020 21:01, Ethan Furman wrote:

A not-great article, White Fears of Dispossession: Dreyer's English, 
The Elements of Style,and the Racial Mapping of English Discourse, here:


http://radicalteacher.library.pitt.edu/ojs/radicalteacher/issue/view/19/25 



Thanks for posting this. (What a lot of work you must've done to find 
it.) As a result I feel I have a much better understanding of the 
environment in which these thought processes (those displayed in the 
commit message) would be considered rational, even admirable. Food for 
thought.


I found the language difficult to understand. For example, "in the midst 
and post the election" instead of "during and after the election". And 
multiply-stacked nouns. And nouns used as verbs. Much like 
"management-speak". If you believe you have something important to say, 
then at least say it clearly.


E. B. White was born in New York -- I believe that's in the northern 
part of the United States, otherwise known as "The North" or the side 
that fought to end slavery.


E. B. White was educated at Cornell.

We should acknowledge that he famously showed an interest in web 
development and invented a sort of mouse. ;-)



___
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/KBX5FZ6VRLYVYRPPBTGCWXLUC27YLAAM/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Recent PEP-8 change

2020-07-02 Thread MRAB

On 2020-07-02 18:19, David Mertz wrote:
On Thu, Jul 2, 2020 at 12:58 PM Piper Thunstrom > wrote:


> TL;DR: It's not a recent usage; it was OK in 1375.

Forgive me for not giving a detailed play by play of 15 years of
experience specifically as a writer and editor.
Over the last handful of decades, singular "they" has been explicitly
taught as inappropriate. My own college writing classes (only 10 years
ago now) included this specific piece of advice.


My college writing class in 1985 or so DID NOT eschew singular they.  
I've been a professional writer for about 30 years now.  I am happy to 
stipulate that your class in 2010 at some particular college included 
an instructor saying "don't use singular they" ... but that was not 
uniform across universities in 2010, probably not even across the 
entire faculty at your particular school.


I'm 55 yo, and I remember 50 years ago hearing the nonsense claim that 
"singular they" is "bad feminists trying to corrupt the English 
language."  I probably didn't know the 14th century origin of the use 
until a decade or two later than that, but this identical discussion 
was already extremely old by the time you were born.


In terms of modern English vernacular, singular "they" has been
continuously and rigorously treated as inappropriate.


This is absolutely and categorically false.  There have been SOME 
PEOPLE who didn't like the singular they, starting about 1820.  The 
idea never occurred to anyone during the first 450 years of its use.  
It has also never been uniform opinion at any point in the last 200 
years.  But as I say, some text books, and quite possibly your 
particular instructor at some particular school, was of that opinion.


Strunk and White, in current editions, does not hold that position.

Those who prefer singular "they", myself included, point to references

very much like yours as evidence that it has a long history of usage.
But until only the last few years, the popular style guides explicitly
forbade it.


Again... SOME guides.  Except the ones that didn't do this.`

And if you don't like singular "they", an alternative that I forgot 
about is "yon", as in this/that/yon (this near me; that near you; yon 
over there by him/her/it). English had 3 demonstratives, as did Latin, 
as does Spanish.


___
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/2PSWJWJITO5TPFHQP5TCGFDQI4BHEHAI/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Recent PEP-8 change

2020-07-02 Thread MRAB

On 2020-07-02 17:47, Piper Thunstrom wrote:

On Thu, Jul 2, 2020 at 12:16 PM MRAB  wrote:
> Here's an article on singular 'they':
>
> https://public.oed.com/blog/a-brief-history-of-singular-they/
>
> TL;DR: It's not a recent usage; it was OK in 1375.

Forgive me for not giving a detailed play by play of 15 years of
experience specifically as a writer and editor.

Over the last handful of decades, singular "they" has been explicitly
taught as inappropriate. My own college writing classes (only 10 years
ago now) included this specific piece of advice.

In terms of modern English vernacular, singular "they" has been
continuously and rigorously treated as inappropriate.

Those who prefer singular "they", myself included, point to references
very much like yours as evidence that it has a long history of usage.
But until only the last few years, the popular style guides explicitly
forbade it.

I hope that helps you understand.


It's also like saying that you shouldn't split infinitives ("to boldly 
go") because Latin doesn't (and can't), or that the copula "be" should 
be followed the nominative case ("It is I", not "It is me") because 
that's what Latin does (on the other hand, French says "C'est moi", not 
"C'est je").


English isn't Latin.
___
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/6YZVBQBU3XI72F4LFU4IRRBHWVYKA5XM/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Recent PEP-8 change

2020-07-02 Thread MRAB

On 2020-07-02 17:14, Paul Moore wrote:

On Thu, 2 Jul 2020 at 16:53, David Mertz  wrote:


On Thu, Jul 2, 2020, 11:08 AM Piper Thunstrom


Paul, this is actually a good question to ask. In general, singular "they" is 
becoming more popular. It's already used frequently for the singular indeterminate 
pronoun:


The first attested use of singular they in English was in 1375 CE. I'm not sure what time 
frame Piper uses as the increment for "becoming more popular", but its use has 
waxed and waned for 650 years.


I was aware of "they" as an option, so I agree it seems like a
reasonable approach.


The usage has never been rare during those 650 years, but neither has it ever 
been predominant. It is a completely reasonable approach, and I would not 
object to encouraging it in Python documentation.


Nor would I.


Earlier in my life (30-40 years ago) I tended to use s/he or similar forms. I 
think that 'they' is more inclusive of gender non-binary people, as well as 
being much more historically established.


I tend to use "they" relatively often, but I have found in the past
that it leads me into certain types of awkward sentences (no, I can't
think of an example right now) where using "they" doesn't seem right.
Maybe that's because I use "he" myself, and feel fairly uncomfortable
when I'm referred to as "they", so that colours my impression - even
though I'm writing for (generic) other people, I do tend to think in
terms of how my words read if I view then as addressed to me. This is
where I feel that "language hasn't caught up".

My understanding is that technically "he" takes a dual role in
English, as both masculine (technical linguistics gender) 3rd person
singular and "indeterminate" 3rd person singular (because English
doesn't have an "indeterminate-but-not-neuter" gender - do any other
languages?). But technical usage is irrelevant here, as people's
feelings and identity are involved and language has to reflect that,
not the other way round. Maybe sometime in the future, "they" will be
the norm and "he and "she" will sound as archaic as "thou" does today.
But until then, I feel that we should all tend to assume that everyone
is *trying* to be inclusive, and shape our words as best we can to
express and include ideas that maybe we don't personally have the
experience to really feel as deeply as others do - that's not so much
"privilege" in my view as "limited experience" and I hope people would
assume I'd like to understand better and mean no harm, rather than
that I'm smugly asserting my own world view as the only one that
matters (sadly, I appreciate that some people *do* do that, but I
doubt that applies to anyone in the Python community...)

Anyway, sermon over - thanks for the information and references everyone.

Indo-European languages tend to have grammatical gender 
(masculine/feminine/neuter or masculine/feminine), but it's not 
necessarily related to physical gender.


Other languages families might have many categories or 'genders', or 
just distinguish between animate and inanimate (and those might not 
necessarily be related to whether something is really animate or inanimate).


Having only one 3rd-person singular pronoun is by no means unusual.
___
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/N4KCCO4FCANKMBRVA6VQZR6QSKJGTWYH/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Flexible assignment targets

2020-07-02 Thread MRAB

On 2020-07-02 15:48, Jim J. Jewett wrote:

Guido van Rossum wrote:

On Wed, Jul 1, 2020 at 5:50 PM Nick Coghlan ncogh...@gmail.com wrote:
> The key thing I'm hoping for in PEP 622 itself is
> that "Syntactic compatibility with a possible future
> enhancement to assignment statements" be considered
> as a constraint on the syntax for case patterns.



That would certainly rule out ideas like writing stores as $x or x? or 
etc., since it would be syntactically incompatible with current
assignment statements.


No; it would be unfortunate that it creates a second way to
do things, but it wouldn't rule them out.  The problem Nick
pointed out is for syntax that is already meaningful, but
means something different.

 self.y = 15

already has a meaning, but that meaning is NOT "don't really
assign to X, I am using it as a constant defined elsewhere."

 ?x = 14
 ?self.y = 15

do not yet mean anything, and if they end up being a more
explicit (but also more verbose) variant of

 x = 14
 self.y = 15

that is probably sub-optimal, but it isn't any worse than :=

The slight variation triggered by the "?" of ?var would be
shorthand for "and if you can't make the entire assignment
work, pretend I never even asked", so that

 ?x, 0 = (4,5)

would not lose or shadow a previous binding of x.
  
IMHO, the assignment statement should remain as it is, not sometimes 
assign and sometimes not.


There could be another form that does matching:

try ?x, 0 = (4,5)

or:

?x, 0 ?= (4,5)

Perhaps it could also be used as an expression, having the value True if 
it matches and False if it doesn't.

___
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/MQV7WBASYRI7PJT5M2VUCPHKBZLXDMY2/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Recent PEP-8 change

2020-07-02 Thread MRAB

On 2020-07-02 15:19, Piper Thunstrom wrote:

On Thu, Jul 2, 2020 at 10:01 AM Paul Moore  wrote:

What *is* the correct inclusive way to refer to an unidentified person
in a technical document, without sacrificing clarity by using
convoluted circumlocutions like "he/her/they" or over-use of the
passive voice? My impression is that commonly accepted language rules
and usage are lagging behind, and there's no good answer to this
question yet :-(

Paul


Paul, this is actually a good question to ask. In general, singular
"they" is becoming more popular. It's already used frequently for the
singular indeterminate pronoun:

"Someone wants to talk to you."
"What do they want?"

Those who favor prescriptivism will tell you this is improper usage
(especially when it goes from an unknown someone to a known someone)
but it avoids the strange construction of "he or she" and is more
inclusive of diverse genders and is historically how the word was
used. (For a fun counter example, the word "you" used to be a plural
second person pronoun, but no one today would argue that it makes no
sense to use it for an individual.)


Here's an article on singular 'they':

https://public.oed.com/blog/a-brief-history-of-singular-they/

TL;DR: It's not a recent usage; it was OK in 1375.
___
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/MIW6WHPO7NZ5UNVPFOIGWH2CI6Y3B5JN/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Recent PEP-8 change

2020-07-02 Thread MRAB

On 2020-07-02 12:32, Greg Ewing wrote:

On 2/07/20 10:53 pm, MRAB wrote:

Alternatively, it could be an auxiliary language like Esperanto.


Maybe Esperanto in particular wouldn't be the best choice --
I gather it's rather European-oriented.

Maybe we should standardise on Klingon? Humans of all cultures
would find it equally difficult.

There are quite a few other constructed languages that you could use, 
but Esperanto is by far the most successful of them, which is why I 
mentioned it.

___
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/A7V3LK44XW7WFB67S7UTT7ZU7HLEFKME/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Recent PEP-8 change

2020-07-02 Thread MRAB

On 2020-07-02 10:38, Chris Angelico wrote:

On Thu, Jul 2, 2020 at 7:27 PM Antoine Pitrou  wrote:

Otherwise why stop at English? I could just as well write my comments
in French if it's all about individual freedom.  Requiring English is
not inclusive, it forced people like me to painfully adapt to a
language I wasn't used to.  And that has nothing to do with "white
supremacy".


True, but "inclusive" isn't just about the people *writing*. If you
write your comments in French, and someone else uses Turkish, another
uses Japanese, and still another opts for Hebrew, it becomes nearly
impossible for anyone to *read* those comments. Standardizing on a
single language ensures that everyone can read the comments in a
single, consistent language.

If we want to be completely fair to everyone, we could insist that
comments be written in Latin. That way, nobody gets a "home turf"
advantage, and we're all going to the effort of translation... but I'm
sure you agree that this wouldn't be an improvement to Python :)

So if there's going to be one language chosen, logically it should be
a language that is familiar to many people. That means that Mandarin
Chinese, Spanish, and English, I believe, would be the most favoured
choices. Chinese has the toughest demands on input methods, and
between Spanish and English, I'd need to hear from someone whose first
language is Spanish as to how viable it would be. But it's still
necessary to standardize on just one.


Alternatively, it could be an auxiliary language like Esperanto.
___
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/2S4TQASCPZKPHYXMCC43ZNKRLWBZN2BW/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: PEP 622: Structural Pattern Matching

2020-06-25 Thread MRAB

On 2020-06-25 08:50, Anders Munch wrote:

Eric Nieuwland :

I have some doubt about the keyword

Guido van Rossum [mailto:gu...@python.org]:

Many people have tried to come up with a different keyword here, but nothing
has been found that comes even close to the simplicity of match. Plus, several
other languages (Scala, Rust) use it too (which is further evidence that it's
a natural fit).
  
I was thinking that 'match' and 'case' are reversed: The top line presents the

_case_ to be studied.  The patterns that follow try to _match_ the presented 
case.

Trying it out on PEP example:

case input:
 match x if x > MAX_INT:
 print("Got a large number")

I think it reads well, in particular when like here there's a condition
attached.  The second line is almost English: "match x if x greater than max
int".

Pascal is a precedent for this placement of 'case', although of course Niklaus
Wirth is not a native English speaker either.

Some languages use 'case' at the start of the construct; other languages 
use 'case' for the individual values. There are precedents for both 
placements.

___
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/R5QZSTDW2UIVYO32GT2L5UZTM7LHD4AU/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: PEP 622: Structural Pattern Matching

2020-06-25 Thread MRAB

On 2020-06-25 04:54, Greg Ewing wrote:

I had another thought about a way to make the bound names explicit.

 # Keyword
 case Point(x -> px, y -> py):

 # Positional
 case Point(-> x, -> y):

 # Sub-pattern, positional
 case Line(Point() -> p1, Point() -> p2):

 # Sub-pattern, keyword
 case Line(start: Point() -> p1, end: Point() -> p2):

How do you indicate that you want it to match anything and don't care 
about the value?

___
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/MKK622JE6SNUSPUJOJPWH3MZ6XH3HV7M/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: PEP 622: Structural Pattern Matching

2020-06-24 Thread MRAB

On 2020-06-24 23:14, Ethan Furman wrote:

On 06/24/2020 01:49 PM, Tim Peters wrote:


I too thought "why not else:?" at first. But "case _:" covers it in
the one obvious way after grasping how general wildcard matches are.


"case _:" is easy to miss -- I missed it several times reading through the PEP.


Introducing "else:" too would be adding a wart (redundancy) just to
stop shallow-first-impression whining.


Huh.  I would consider "case _:" to be the wart, especially since "case default:" or "case 
anything:" or "case i_dont_care:" all do basically the same thing (although they bind to the given name, 
while _ does not bind to anything, but of what practical importance is that?) .[snip]


The point of '_' is that it can be used any number of times in a pattern:

case (_, _):

This is not allowed:

case (x, x):

When a pattern matches, binding occurs, and why bind to a name when you 
don't need/want the value?

___
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/7LT5QOEMLVUPT6TNKLIWCN3I4F3XHMTD/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: PEP 622: Structural Pattern Matching

2020-06-24 Thread MRAB

On 2020-06-24 13:37, Antoine Pitrou wrote:

On Wed, 24 Jun 2020 21:54:24 +1200
Greg Ewing  wrote:

On 24/06/20 5:20 am, Antoine Pitrou wrote:
> suddently `Point(x, 0)` means something entirely
> different (it doesn't call Point.__new__, it doesn't lookup `x` in the
> locals or globals...).  


This is one reason I would rather see something explicitly marking
names to be bound, rather than making the binding case the default.
E.g.

case Point(?x, 0):

This would also eliminate the need for the awkward leading-dot
workaround for names to be looked up rather than bound.


That looks quite a bit better indeed, because it strongly suggests
that something unusual is happening from the language's POV. Thank you
for suggesting this.


Could the name be omitted when you're not interested in the value?

case Point(?, 0):


One other thing that the PEP doesn't make clear -- is it possible
to combine '=' and ':=' to match a keyword argument with a sub
pattern and capture the result? I.e. can you write

case Spam(foo = foo_value := Blarg()):


Yuck :-S


___
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/TQYW7GRPXWNHM7NWDKVQZCDZZBFZYVHN/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: PEP 622: Structural Pattern Matching

2020-06-23 Thread MRAB

On 2020-06-24 01:09, Guido van Rossum wrote:
On Tue, Jun 23, 2020 at 4:41 PM MRAB <mailto:pyt...@mrabarnett.plus.com>> wrote:

[snip]


However, what if you wanted to match Ellipsis?

This could lead to bugs:

 >>> ...
Ellipsis
 >>> Ellipsis = 0
 >>> Ellipsis
0
 >>> ...
Ellipsis


Now you're just being silly. If you want to use Ellipsis as a variable 
you can't also use it to refer to the "..." token.

[snip]

The point here is that printing ... shows "Ellipsis" (not "..."), 
printing None shows "None", etc.


Printing Ellipsis also shows "Ellipsis", but you can bind to it. You 
can't bind to None, 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/UZCECU4MCYBCI7EOZQM522ZCOZEKVHIX/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: PEP 622: Structural Pattern Matching

2020-06-23 Thread MRAB

On 2020-06-23 22:50, Barry Warsaw wrote:

On Jun 23, 2020, at 14:31, Chris Angelico  wrote:


I can't find it among the rejected alternatives, but was it considered
to use "..." as the wildcard, rather than "_"? It carries similar
meaning but its special case of "this will never be bound" is simply
preventing an error, rather than making one otherwise-valid name
special.


I thought of that too as I was reading the PEP, but forgot to add it to my 
notes.  I do like ellipsis more than underscore here.


+1

However, what if you wanted to match Ellipsis?

This could lead to bugs:

>>> ...
Ellipsis
>>> Ellipsis = 0
>>> Ellipsis
0
>>> ...
Ellipsis

If you can have "case False:" and "case True:", should 'Ellipsis' become 
a keyword so that you could have "case Ellipsis:"? Or do they have to be 
"case .False:", "case .True:", in which case it could remain "case 
.Ellipsis:"?

___
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/ZM6YWTIHNBJ6JJPTFOQNWIPIV4CO3UPX/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: PEP 622: Structural Pattern Matching

2020-06-23 Thread MRAB

On 2020-06-23 22:53, Emily Bowman wrote:
On Tue, Jun 23, 2020 at 2:10 PM MRAB <mailto:pyt...@mrabarnett.plus.com>> wrote:


I think that's done for consistency. '_' is a wildcard and you can
have:

     case (_, _):

to match any 2-tuple, so:

     case _:

would match any value, and can thus already serve as the default.

I wouldn't object to 'else', though.


Can you have case (x,x): ? I haven't tried the implementation, but 
it's not addressed in the PEP that I see, and if that's legal, then _ 
is effectively just a style choice, rather than a functional one, and 
there's no reason it shouldn't also be a named match.



You cannot bind to the same name twice, so "case (x,x):"is an error.
+1 for including "else:" for consistency even if that's just a shim 
for "case _:"

___
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/6KXFMJ3M372GJO6UI5GFSAKETTNUF5HO/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: PEP 622: Structural Pattern Matching

2020-06-23 Thread MRAB

On 2020-06-23 18:20, Antoine Pitrou wrote:


Some comments:

* What you call "Constant Value Patterns" can really refer to any local
   or non-local name, regardless of how complex the referred object is,
   right?  Also, __eq__ is called in that case, not __match__?

* If I understand correctly, these:

 case b"":
 print("it's an empty bytes object")

and

 case bytes():
 print("it's a bytes object")

have entirely different meanings.  Am I right?  This sounds like I have
to switch contexts when reading code, based on whether I am reading
regular code or a match clause, given that semantics are quite
different.

Instead, it seems like the latter would be more explicitly spelled out
as, e.g.:

 case instanceof(bytes):
 print("it's a bytes object")

* The acronym "ADT" is never defined.

* """If there are more positional items than the length of
   __match_args__, an ImpossibleMatchError is raised."""

What if there are less positional items than ``len(__match_args__)``?
Can the match succeed rather than raise ImpossibleMatchError?  This
seems potentially error-prone.


Overall, my main concern with this PEP is that the matching semantics
and pragmatics are different from everything else in the language.
When reading and understanding a match clause, there's a cognitive
overhead because suddently `Point(x, 0)` means something entirely
different (it doesn't call Point.__new__, it doesn't lookup `x` in the
locals or globals...).  Obviously, there are cases where this is
worthwhile, but still.

It may be useful to think about different notations for these new
things, rather than re-use the object construction notation.

For example:

 case Point with (x, y):
  print(f"Got a point with x={x}, y={y}")

or:

 case Point @ (x, y):
  print(f"Got a point with x={x}, y={y}")

(yes, "@" is the matrix multiplication operator... but it's probably
much less likely to appear in common code and especially with a class
object at the left)


Or:

case Point as (x, y):
print(f"Got a point with x={x}, y={y}")

perhaps as 'as' is already used for binding.

The disadvantage there is with nested patterns:

case Coordinate(Point(x1, y1), Point(x2, y2)):

where you're matching a coordinate and binding to x1, y1, x2 and y2.
___
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/IMKBETFAH3CS6TLBT3JNQX2ULQ4QKQLK/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: PEP 622: Structural Pattern Matching

2020-06-23 Thread MRAB

On 2020-06-23 20:27, Rob Cliffe via Python-Dev wrote:



On 23/06/2020 17:01, Guido van Rossum wrote:


You can combine several literals in a single pattern using `|` ("or"):

```py
        case 401|403|404:
            return "Not allowed"
The PEP is great, but this strikes me as horribly confusing, given that 
401|403|404 is already legal syntax.
IIUC any legal expression can come between `case` and `:`, but 
expressions that contain `|` at their outermost level are *interpreted 
differently* than from in other contexts.


The grammar shows that 'case' is followed by a series of alternatives, 
separated by '|', but the alternatives aren't expressions, basically 
only literals and instances of a given class. You can't say "case 1 + 
2:", for example.



Presumably adding parentheses:
     case (401|403|404):
would make it equivalent to
     case 407:


I'm not sure whether that's legal, but it's not equivalent.

Is a separator (other than whitespace) actually needed?  Can the parser 
cope with

     case 401 403 404:

Failing that IMO preferable, albeit not ideal, possibilities would be
   1) Use colon as the separator.
   2) Use comma as the separator - this is already legal syntax too, but 
IMO it reads more naturally.
   (And IIRC there are already contexts where brackets are necessary 
to indicate a tuple.)

Perhaps someone can think of something better.

I also (with others) prefer `else:` or perhaps `case else:` to using 
the`_` variable.
The latter is obscure, and woudn't sit well with code that already uses 
that variable for its own purposes.



I think that's done for consistency. '_' is a wildcard and you can have:

case (_, _):

to match any 2-tuple, so:

case _:

would match any value, and can thus already serve as the default.

I wouldn't object to 'else', 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/SACSWYRDR5Q6LUPAMJCX455RKZ6ZFSY2/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: PEP 622: Structural Pattern Matching

2020-06-23 Thread MRAB

On 2020-06-23 17:01, Guido van Rossum wrote:
I'm happy to present a new PEP for the python-dev community to review. 
This is joint work with Brandt Bucher, Tobias Kohn, Ivan Levkivskyi and 
Talin.


Many people have thought about extending Python with a form of pattern 
matching similar to that found in Scala, Rust, F#, Haskell and other 
languages with a functional flavor. The topic has come up regularly on 
python-ideas (most recently yesterday :-).


I'll mostly let the PEP speak for itself:
- Published: https://www.python.org/dev/peps/pep-0622/ (*)
- Source: https://github.com/python/peps/blob/master/pep-0622.rst

(*) The published version will hopefully be available soon.

I want to clarify that the design space for such a match statement is 
enormous. For many key decisions the authors have clashed, in some cases 
we have gone back and forth several times, and a few uncomfortable 
compromises were struck. It is quite possible that some major design 
decisions will have to be revisited before this PEP can be accepted. 
Nevertheless, we're happy with the current proposal, and we have 
provided ample discussion in the PEP under the headings of Rejected 
Ideas and Deferred Ideas. Please read those before proposing changes!


I'd like to end with the contents of the README of the repo where we've 
worked on the draft, which is shorter and gives a gentler introduction 
than the PEP itself:



# Pattern Matching

This repo contains a draft PEP proposing a `match` statement.

Origins
---

The work has several origins:

- Many statically compiled languages (especially functional ones) have
   a `match` expression, for example
   
[Scala](http://www.scala-lang.org/files/archive/spec/2.11/08-pattern-matching.html),

   [Rust](https://doc.rust-lang.org/reference/expressions/match-expr.html),
   
[F#](https://docs.microsoft.com/en-us/dotnet/fsharp/language-reference/pattern-matching);

- Several extensive discussions on python-ideas, culminating in a
   summarizing
   [blog 
post](https://tobiaskohn.ch/index.php/2018/09/18/pattern-matching-syntax-in-python/)

   by Tobias Kohn;
- An independently developed [draft
   
PEP](https://github.com/ilevkivskyi/peps/blob/pattern-matching/pep-.rst)

   by Ivan Levkivskyi.

Implementation
--

A full reference implementation written by Brandt Bucher is available
as a [fork]((https://github.com/brandtbucher/cpython/tree/patma)) of
the CPython repo.  This is readily converted to a [pull
request](https://github.com/brandtbucher/cpython/pull/2)).

Examples


Some [example 
code](https://github.com/gvanrossum/patma/tree/master/examples/) is 
available from this repo.


Tutorial


A `match` statement takes an expression and compares it to successive
patterns given as one or more `case` blocks.  This is superficially
similar to a `switch` statement in C, Java or JavaScript (an many
other languages), but much more powerful.

The simplest form compares a target value against one or more literals:

```py
def http_error(status):
     match status:
         case 400:
             return "Bad request"
         case 401:
             return "Unauthorized"
         case 403:
             return "Forbidden"
         case 404:
             return "Not found"
         case 418:
             return "I'm a teapot"
         case _:
             return "Something else"
```

Note the last block: the "variable name" `_` acts as a *wildcard* and
never fails to match.

You can combine several literals in a single pattern using `|` ("or"):

```py
         case 401|403|404:
             return "Not allowed"
```

Patterns can look like unpacking assignments, and can be used to bind
variables:

```py
# The target is an (x, y) tuple
match point:
     case (0, 0):
         print("Origin")
     case (0, y):
         print(f"Y={y}")
     case (x, 0):
         print(f"X={x}")
     case (x, y):
         print(f"X={x}, Y={y}")
     case _:
         raise ValueError("Not a point")
```

Study that one carefully!  The first pattern has two literals, and can
be thought of as an extension of the literal pattern shown above.  But
the next two patterns combine a literal and a variable, and the
variable is *extracted* from the target value (`point`).  The fourth
pattern is a double extraction, which makes it conceptually similar to
the unpacking assignment `(x, y) = point`.

If you are using classes to structure your data (e.g. data classes)
you can use the class name followed by an argument list resembling a
constructor, but with the ability to extract variables:

```py
from dataclasses import dataclass

@dataclass
class Point:
     x: int
     y: int

def whereis(point):
     match point:
         case Point(0, 0):
             print("Origin")
         case Point(0, y):
             print(f"Y={y}")
         case Point(x, 0):
             print(f"X={x}")
         case Point():
             print("Somewhere else")
         case _:
             print("Not a point")
```

We can use 

[Python-Dev] Re: When can we remove wchar_t* cache from string?

2020-06-12 Thread MRAB

On 2020-06-12 09:32, Inada Naoki wrote:

Hi, all.

Py_UNICODE has been deprecated since PEP 393 (Flexible string representation).

wchar_t* cache in the string object is used only in deprecated APIs.
It waste 1 word (8 bytes on 64bit machine) per string instance.

The deprecated APIs are documented as "Deprecated since version 3.3,
will be removed in version 4.0."
See https://docs.python.org/3/c-api/unicode.html#deprecated-py-unicode-apis

But when PEP 393 is implemented, no one expects 3.10 will be released.
Can we reschedule the removal?

My proposal is, schedule the removal on Python 3.11.  But we will postpone
the removal if we can not remove its usage until it.

I grepped the use of the deprecated APIs from top 4000 PyPI packages.

result: 
https://github.com/methane/notes/blob/master/2020/wchar-cache/deprecated-use
step: https://github.com/methane/notes/blob/master/2020/wchar-cache/README.md

I noticed:

* Most of them are generated by Cython.
   * I reported it to Cython so Cython 0.29.21 will fix them.  I expect
more than 1 year
 between Cython 0.29.21 and Python 3.11rc1.
* Most of them are `PyUnicode_FromUnicode(NULL, 0);`
   * We may be able to keep PyUnicode_FromUnicode, but raise error when 
length>0.

I think it would be strange to keep PyUnicode_FromUnicode but complain 
unless length == 0. If it's going to be removed, then remove it and 
suggest a replacement for that use-case, such as PyUnicode_FromString 
with a NULL argument. (I'm not sure if PyUnicode_FromString will accept 
NULL, but if it currently doesn't, then maybe it should in future be 
treated as being equivalent to PyUnicode_FromString("").)

___
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/3CMLZWRTOBTA6NMOZRYS5MF2SY7S5GKM/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Repr: where to place the address and additional info?

2020-05-29 Thread MRAB

On 2020-05-29 21:02, Serhiy Storchaka wrote:

The default repr of Python object is formatted using the following pattern:

  <{typename} object at {address:#x}>

And many custom reprs use similar patterns, but add some additional type
specific information. The type name first, followed by details and
address. All is surrounded by angle quotes. The question is in what
order to show address and other details? Should the address be at rear
or in the middle?

  <{typename} {details} at {address:#x}>
  <{typename} at {address:#x} {details}>

There are examples of both ways in the stdlib. I am going to add new
custom reprs [1] and need to know what pattern looks better.

Also, is "object" mandatory after the type name?

  <{typename} object {details} at {address:#x}>
  <{typename} object at {address:#x} {details}>

[1] https://bugs.python.org/issue24391

FWIW, my preference is for the address at the end for reasons already 
stated in the issue.

___
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/JK2LVYUTO4VJHFERETLD2RJLNJJVARKB/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip

2020-05-20 Thread MRAB

On 2020-05-21 00:29, Emily Bowman wrote:
Python has always preferred full-word over old-school C/Perl/PHP-style 
abbreviated names. Clarity is paramount. (Or this whole discussion 
wouldn't even be happening.)



[snip]
... apart from len, def, int, float, str, 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/CXRBJETQJNBE27K3ASEB4H47BD4NYHE7/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip

2020-05-15 Thread MRAB

On 2020-05-15 20:36, David Mertz wrote:
On Fri, May 15, 2020 at 12:55 PM Eric V. Smith > wrote:


Also: The PEP says "At most one additional item may be consumed from
one of the iterators when compared to normal zip usage." I think
this should be prefaced with "If ValueError is raised ...". Also,
why does it say "at most one additional item". How could it ever be
less than one?


This struck me as strange also.  I mean, the wording can be improved to 
clarify "if error."


But more significantly, it seems like it cannot conceivably be true.  If 
might be "At most one additional item from EACH of the iterators."


If I do zip_strict(a, b, c, d, e) and "e" is the one that is shorter, 
how could any algorithm ever avoid consuming one extra item of a, b, c, 
and d each?!



Well, it does say "when compared to normal zip usage".

The normal zip would consume an item of a, b, c, and d. If e is 
exhausted, then zip would just stop, but zip_strict would raise 
ValueError. There would be no difference in the number of items consumed 
but not used.

___
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/5B26LEJYDRIFCP3ETEAWLJJFV76PUKQ4/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes

2020-03-22 Thread MRAB

On 2020-03-22 05:00, Dennis Sweeney wrote:

I like "removeprefix" and "removesuffix". My only concern before had been length, but 
three more characters than "cut***fix" is a small price to pay for clarity.


How about "dropprefix" and "dropsuffix"?
___
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/UL3SAVB3RGFTRFERG3J3VQNPQBXWTV7G/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes

2020-03-20 Thread MRAB

On 2020-03-20 21:49, Dennis Sweeney wrote:

For clarity, I'll change

  If ``s`` does not have ``pre`` as a prefix, an unchanged copy of ``s`` is 
returned.

to

 If ``s`` does not have ``pre`` as a prefix, then ``s.cutprefix(pre)`` 
returns ``s`` or an unchanged copy of ``s``.

For consistency with the Specification section, I'll also change

 s[len(pre):] if s.startswith(pre) else s

to

 s[len(pre):] if s.startswith(pre) else s[:]

and similarly change the ``cutsuffix`` snippet.


If ``s`` is immutable, why return a copy when the original will do?

s[len(pre) : ] if pre and s.startswith(pre) else s

s[ : -len(suf)] if suf and s.endswith(suf) else s
___
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/AP6L5H4H3E3RP6FZD4NS6NTLNV4KCQMM/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Request to postpone some Python 3.9 incompatible changes to Python 3.10

2020-01-31 Thread MRAB

On 2020-01-31 19:58, Ethan Furman wrote:

On 01/31/2020 10:47 AM, Mike Miller wrote:

On 2020-01-23 07:20, Victor Stinner wrote:



Python 3.9 introduces many small incompatible changes which broke tons


There's a well-known and established way of signaling breaking changes in 
software platforms—it is to increment the major version number.

Rather than debating the merits of breaking code on 3.9 or 3.10, wouldn't it 
make more sense to do it in a Python 4.0 instead?


I've gotta say, I like that plan.  Instead of going to x.10, go to x+1.0.  
Every ten years we bump the major version and get rid of all the deprecations.


It has a certain appeal for me too.
___
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/Q24LBBZ4P2PAUBU5B2K7HNXP3HJXFBEP/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Python 3.8 error?

2019-12-09 Thread MRAB

On 2019-12-09 18:22, Christian Tismer wrote:

On 08.12.19 09:49, Nick Coghlan wrote:

On Fri., 6 Dec. 2019, 3:31 am Christian Tismer, mailto:tis...@stackless.com>> wrote:

Hi guys,

during the last few weeks I have been struggling quite much
in order to make PySide run with Python 3.8 at all.

The expected problems were refcounting leaks due to changed
handling of heaptypes. But in fact, the runtime behavior was
much worse, because I always got negative refcounts!

After exhaustive searching through the different 3.8 commits, I could
isolate the three problems with logarithmic search.

The hard problem was this:
Whenever PySide creates a new type, it crashes in PyType_Ready.
The reason is the existence of the Py_TPFLAGS_METHOD_DESCRIPTOR
flag.
During the PyType_Ready call, the function mro() is called.
This mro() call results in a negative refcount, because something
behaves differently since this flag is set by default in mro().

When I patched this flag away during the type_new call, everything
worked ok. I don't understand why this problem affects PySide
at all. Here is the code that would normally be only the newType line:


    // PYSIDE-939: This is a temporary patch that circumvents the
problem
    // with Py_TPFLAGS_METHOD_DESCRIPTOR until this is finally solved.
    PyObject *ob_PyType_Type = reinterpret_cast(_Type);
    PyObject *mro = PyObject_GetAttr(ob_PyType_Type,
Shiboken::PyName::mro());
    auto hold = Py_TYPE(mro)->tp_flags;
    Py_TYPE(mro)->tp_flags &= ~Py_TPFLAGS_METHOD_DESCRIPTOR;
    auto *newType = reinterpret_cast(type_new(metatype,
args, kwds));
    Py_TYPE(mro)->tp_flags = hold;


Isn't this manipulating the flags in the tuple type, rather than
anything on a custom object? Or is "mro" a custom object rather than an
MRO tuple?

If anything, given the combination of factors required to reproduce the
problem, I would guess that there might be a ref counting problem in the
__set_owner__ invocations when called on a new type rather than a
regular instance, and that was somehow affected by the change to
increment the type refcount in PyObject_Init rather than
PyType_GenericAlloc.



Hi Nick,

after staring long at the code, I fount something funny in
typeobject.c #286 ff:


static void
type_mro_modified(PyTypeObject *type, PyObject *bases) {
 /*
Check that all base classes or elements of the MRO of type are
able to be cached.  This function is called after the base
classes or mro of the type are altered.

Unset HAVE_VERSION_TAG and VALID_VERSION_TAG if the type
has a custom MRO that includes a type which is not officially
super type, or if the type implements its own mro() method.

Called from mro_internal, which will subsequently be called on
each subclass when their mro is recursively updated.
  */
 Py_ssize_t i, n;
 int custom = (Py_TYPE(type) != _Type);
 int unbound;
 PyObject *mro_meth = NULL;
 PyObject *type_mro_meth = NULL;

 if (!PyType_HasFeature(type, Py_TPFLAGS_HAVE_VERSION_TAG))
 return;

 if (custom) {
 _Py_IDENTIFIER(mro);
 mro_meth = lookup_maybe_method(
 (PyObject *)type, _mro, );
 if (mro_meth == NULL)
 goto clear;
 type_mro_meth = lookup_maybe_method(
 (PyObject *)_Type, _mro, );
 if (type_mro_meth == NULL)
 goto clear;
 if (mro_meth != type_mro_meth)
 goto clear;
 Py_XDECREF(mro_meth);
 Py_XDECREF(type_mro_meth);
 }


Look at the "if (custom)" clause.
"mro_meth = lookup_maybe_method(" uses lookup_maybe_method which
gives a borrowed reference. The same holds for "type_mro_meth".

But then both are decreffed, which IMHO is not correct.


Look at what happens at the label "clear": it DECREFs them.

If mro_meth != NULL or mro_meth != type_mro_meth, they'll get DECREFed 
at "clear".

___
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/EZ3ETF5LJEO3Q2NKUXWRZ54IQK744NVZ/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Implementation of PEP-0604

2019-11-17 Thread MRAB

On 2019-11-17 20:09, Ivan Levkivskyi wrote:
To add some more input about forward references, here are couple of 
thoughts:


1. I think ideally we should support forward references to the same 
extent they are currently supported:
i.e. Union[None, "ForwardRef"], Union["OtherForwardRef", None], and 
Union["ForwardRef", "OtherForwardRef"]
should all be supported. The last one looks the hardest, in the sense 
that it looks like we will need

to add `str.__or__()` to support these forms.

I'm not sure I like the thought of adding `str.__or__()` because it 
would mean that "Foo" | "Bar" becomes valid and returns a type, which is 
unexpected.


Perhaps an alternative would be to add 'Forward' to make it explicit:

Forward("ForwardRef") | Forward("OtherForwardRef")

or just:

Forward("ForwardRef") | "OtherForwardRef"

2. Forward references to type variables were never supported and we 
shouldn't start supporting this
(even if it accidentally worked in some situations). Type variables 
should always be defined before use.

So I think we should not worry about point 3 in Richard's e-mail.

Philippe, I think it makes sense to reflect these points to the PEP draft.


[snip]


On Thu, 14 Nov 2019 at 02:23, Richard Eames > wrote:


Thanks for the encouragement!

I've been working some more on it since I had some more free cycles
in the last few days and I think I've got to the limit of my
capabilities. I think I've got it to a point where it needs more
eyes because my experience level writing code in the python
interpreter is pretty low, so I know that I have holes in there,
especially around using INCREF/DECREF.
I'm currently stuck on 3 things:

1. repr( pickle.loads( pickle.dumps(int | str) ) ) causes an
infinite recursion that I can't figure out. I might end up
re-specializing `repr()` again since it isn't defined in the PEP.

2.
- `None | "forwardref"` and `None | None`
- `"forwardref" | None` and `"forwardRefA" | "forwardRefB"`
I've had a go at adding a `type.__ror__` as suggested by GvR, but I
think I'm missing something.

3. type parameters
- I'm not sure how to handle this:
```
MaybeT = None | "T" # creates shadow union
T = TypeVar('T')
maybe_int = MaybeT[int] # should this stay in shadow land, or go
back to typing.py
isinstance(1, maybe_int)
isinstance(1, MaybeT[int])
```
I have a couple options for this:
- implement the type substitution in c; which can be done, but feels
like overkill?
- store the type parameters on the shadow object and vivify when
needed (which will end up being in the isinstance call)
- implement the __getitem__ as a call into the typing.py library and
promote as it's requested. This is how I've currently implemented it.

I'm happy to keep going on this if/when needed,


___
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/KILH2EA4NTKGYDIROEOQ6GGJ2KLV55X4/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: [RELEASE] Python 3.8.0 is now available

2019-10-15 Thread MRAB

On 2019-10-15 19:03, MRAB wrote:

On 2019-10-14 21:23, Łukasz Langa wrote:
On behalf of the Python development community and the Python 3.8 release 
team, I’m pleased to announce *the availability of Python 3.8.0*.



[snip]
I've installed pywin32 on Python 3.8, but when I try to import
win32clipboard it says it can't find it:

Python 3.8.0 (tags/v3.8.0:fa919fd, Oct 14 2019, 19:37:50) [MSC v.1916 64
bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
  >>> import win32
  >>> import win32clipboard
Traceback (most recent call last):
File "", line 1, in 
ImportError: DLL load failed while importing win32clipboard: The
specified module could not be found.
  >>>

Does anyone else have this problem?

I found the solution: copy pywintypes38.dll and pythoncom38.dll from 
site-packages/pywin32_system32 into site-packages/win32.

___
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/NQKC533WWIFD5BYPWH2QULSO2ECSRVOP/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: [RELEASE] Python 3.8.0 is now available

2019-10-15 Thread MRAB

On 2019-10-14 21:23, Łukasz Langa wrote:
On behalf of the Python development community and the Python 3.8 release 
team, I’m pleased to announce *the availability of Python 3.8.0*.



[snip]
I've installed pywin32 on Python 3.8, but when I try to import 
win32clipboard it says it can't find it:


Python 3.8.0 (tags/v3.8.0:fa919fd, Oct 14 2019, 19:37:50) [MSC v.1916 64 
bit (AMD64)] on win32

Type "help", "copyright", "credits" or "license" for more information.
>>> import win32
>>> import win32clipboard
Traceback (most recent call last):
  File "", line 1, in 
ImportError: DLL load failed while importing win32clipboard: The 
specified module could not be found.

>>>

Does anyone else have this problem?
___
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/MHSHP3Z5TN4SDSG6G3MLAV6H56C36DHP/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Compacting the Uncompactable

2019-09-28 Thread MRAB
Here's a video about memory fragmentation and compaction that you might 
find interesting:


"Compacting the Uncompactable" by Bobby Powers
https://www.youtube.com/watch?v=c1UBJbfR-H0
___
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/G6OR45TETKIFZDVWAK5ZGLLFTIC422TG/


[Python-Dev] Re: static variables in CPython - duplicated _Py_IDENTIFIERs?

2019-09-23 Thread MRAB

On 2019-09-23 21:22, Vinay Sajip via Python-Dev wrote:

OK - but that's just one I picked at random. There are others like it - what 
would be the process for deciding which ones need to be made private and moved? 
Should an issue be raised to track this?

It's not really a question of which ones should be made private, but of 
which ones should be remain public. If it's mentioned in the docs, then 
it's public, otherwise it should be private.
How easy would it be to search the sources and the docs for the ones 
that are currently public but not documented?

___
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/4KUPJBNXXL7VD6JPAC7YCCTD56A5OUAZ/


[Python-Dev] Re: Spammy stuff (was Re: congrats on 3.5! Alas, windows 7 users are having problems installing it)

2019-09-15 Thread MRAB

On 2019-09-15 23:40, Michael Foord wrote:



Sent from my iPhone


On 15 Sep 2019, at 23:25, Tim Peters  wrote:

[Tim]

While python-dev has several "official" moderators, best I can tell
I'm the only one who has reviewed these messages for years.


I should clarify that!  That's not meant to be a dig at the other
moderators.  I review everything because I'm retired and am near the
computer many hours almost every day.  That's been so for at least a
decade.  So the others rarely get a chance - the queue is very likely
empty if they ever look.  After a few years of that, they may well
stop looking ;-)


Personally I resent anything that takes time away from you making posts on 
Facebook.

I hope you're not going to start a thread entitled "What has Tim Peters 
ever done for us?" :-)

___
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/5QMQ2OZWXJDLKNHOU7ZNNAMXTSZTBYKH/


[Python-Dev] Re: What to do about invalid escape sequences

2019-08-09 Thread MRAB

On 2019-08-09 23:56, Steven D'Aprano wrote:

I'm not trying to be confrontational, I'm trying to understand your
use-case(s) and see if it would be broken by the planned change to
string escapes.


On Fri, Aug 09, 2019 at 03:18:29PM -0700, Glenn Linderman wrote:

On 8/9/2019 2:53 PM, Steven D'Aprano wrote:
>On Fri, Aug 09, 2019 at 01:12:59PM -0700, Glenn Linderman wrote:
>
>>The reason I never use raw strings is in the documentation, it is
>>because \ still has a special meaning, and the first several times I
>>felt the need for raw strings, it was for directory names that wanted to
>>end with \ and couldn't.
>Can you elaborate? I find it unlikely that I would ever want a docstring

I didn't mention docstring.  I just wanted a string with a path name 
ending in \.


You said you never used raw strings in the documentation. I read that as
doc strings. What sort of documentation are you writing that isn't a doc
string but is inside your .py files where the difference between raw and
regular strings is meaningful?


Windows users are used to seeing backslashes in paths, I don't care to 
be the one to explain why my program uses / and all the rest use \.


If you don't use raw strings for paths, you get to explain why your
program uses \\ and all the rest use \ *wink*

If they're Windows end users, they won't be reading your source code and
will never know how you represent hard-coded paths in the source code.

If they're Windows developers, they ought to be aware that the Windows
file system API allows / anywhere you can use \ and it is the
common convention in Python to use forward slashes.

I'm also curious why the string needs to *end* with a backslash. Both of
these are the same path:

 C:\foo\bar\baz\
 C:\foo\bar\baz



The only time it's required is for the root directory of a drive:

C:\
___
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/GIPRSYAINB4NE4IORCYRTYN7TZWMCZ34/


[Python-Dev] Re: What to do about invalid escape sequences

2019-08-07 Thread MRAB

On 2019-08-07 23:43, Steve Holden wrote:
This whole thread would be an excellent justification for following 3.9 
with 4.0. It's as near as we ever want to get to a breaking change, and 
a major version number would indicate the need to review. If increasing 
strictness of escape code interpretation in string literals is the only 
incompatibility there would surely be general delight.



I can think of another possible one: import * requires __all__.

[snip]
___
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/WQEHMFMR7IRWYDXDSCZUGJKGDI5HNEDK/


[Python-Dev] Re: What to do about invalid escape sequences

2019-08-06 Thread MRAB

On 2019-08-06 17:32, Matt Billenstein wrote:

On Mon, Aug 05, 2019 at 04:22:50AM -, raymond.hettin...@gmail.com wrote:

This once seemed like a reasonable and innocuous idea to me; however, I've
been using the 3.8 beta heavily for a month and no longer think it is a good
idea.  The warning crops up frequently, often due to third-party packages
(such as docutils and bottle) that users can't easily do anything about.


Perhaps those packages could be flagged now via pylint and problems raised with
the respective package maintainers before the actual 3.8 release?  Checking the
top 100 or top 1000 packages on PyPI?

Or it could be deferred until Python 4.0. Are there any other issues 
where we could say that from Python 4.0 you shouldn't do X?

___
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/LKNAPPAYOMXVQJI2TPDCKV277ZWGSOWR/


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

2019-07-23 Thread MRAB

On 2019-07-23 21:59, Kristian Klette wrote:

Hi!

During the sprints after EuroPython, I made an attempt at adding support for
comparing the results from `.values()` of two dicts.

Currently the following works as expected:

```
d = {'a': 1234}

d.keys() == d.keys()
d.items() == d.items()
```

but `d.values() == d.values()` does not return the expected
results. It always returns `False`. The symmetry is a bit off.

In the bug trackers[0] and the Github PR[1], I was asked
to raise the issue on the python-dev mailing list to find
a consensus on what comparing `.values()` should do.

I'd argue that Python should compare the values as expected here,
or if we don't want to encourage that behaviour, maybe we should
consider raising an exception.
Returning just `False` seems a bit misleading.

What are your thoughts on the issue?

Best regards,
Kristian Klette


[0]: https://bugs.python.org/issue37585
[1]: https://github.com/python/cpython/pull/14737


Well, the keys can function as a set, and, in fact, can equal a set:

>>> {'a': 1234}.keys() == {'a'}
True

so the keys of 2 dicts can be compared efficiently.

The items of 2 dicts can also be compared efficiently because you still 
have the keys, so you can check the key efficiently and then check the 
value.


However, when comparing the values you have a problem: you have 2 
collections of objects that might contain duplicates, might not be 
hashable, and might not be sortable, so comparing them could be 
inefficient, and you can't refer back to their keys like in the case of 
comparing the items as above because the 2 dicts might have different 
keys. Unless someone can come up with an efficient solution, I'd 
probably go with raising an exception.

___
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/SBIYA5JAB3AUVBLQDXMT4CFSYSU76CNF/


[Python-Dev] Re: strip behavior provides inconsistent results with certain strings

2019-06-28 Thread MRAB

On 2019-06-28 03:40, Glenn Linderman wrote:

On 6/27/2019 3:09 PM, Brett Cannon wrote:

My guess is that without Guido to just ask this will have to go to a PEP as it 
changes a built-in.

How does adding two new methods change a built-in?

Now if an extra parameter were added to modify lstrip, rstrip, and strip 
to make them do something different, yes.


But adding new methods doesn't change anything, unless someone is 
checking for their existence.


My preferred color is  pstrip and sstrip (prefix and suffix strip) since 
lstrip and rstrip mean left and right.


And maybe there should be a psstrip, that takes two parameters, the 
prefix and the suffix to strip.


Such functions would certainly reduce code in a lot of places where I do

if  string.startswith('foo'):
     string = string[ 3: ];

as well as making it more robust, because the string and its length have 
to stay synchronized when changes are made.


lstrip and rstrip remove treat the argument as a set of characters and 
can remove multiple characters, so having additional methods pstrip and 
sstrip with their very similar names but different behaviours could be 
confusing.


I'd prefer to stick with lXXX and rXXX. ldrop and rdrop, maybe?
___
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/JRKVJHS63GCC5T4UCY7BNB6OU2TPY6GR/


[Python-Dev] Re: Who uses libpython38.a on Windows?

2019-06-14 Thread MRAB

On 2019-06-14 21:53, Steve Dower wrote:

One of the most annoying steps in building the Windows installers is
generating the libpython38.a file. It's annoying, because it requires
having "generic enough" MinGW tools to ensure that the file is
compatible with whatever version of MinGW might be trying to build
against the regular Windows distribution.

I would like to stop shipping this file in 3.8 and instead put the steps
into the docs to show people how to generate them themselves (with the
correct version of their tools):

gendef python38.dll > tmp.def
dlltool --dllname python38.dll --def tmp.def --output-lib libpython38.a
-m i386:x86-64

(Obviously the commands themselves are not complicated if you already
have gendef and dlltool, but currently a normal CPython build system
does not have these.)

Before just doing this, I wanted to put out a request for information:

* Do you rely (or know anyone who relies) on libpython38.a on Windows?
* Are you able to add the two commands above to your build? If not, why not?

I'm able to build the regex module without it; in fact, I believe I've 
been able to do so since Python 3.5!

___
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/A7IXOTARTYJUNSCFAU3YY2VOVILC4EBY/


Re: [Python-Dev] [PEP 558] thinking through locals() semantics

2019-06-02 Thread MRAB

On 2019-06-02 13:51, Steven D'Aprano wrote:

On Sun, Jun 02, 2019 at 11:52:02PM +1200, Greg Ewing wrote:

Armin Rigo wrote:
>You have the occasional big function that benefits a lot from being
>JIT-compiled but which contains ``.format(**locals())``.

There should be a lot less need for that now that we have f-strings.


I think you're forgetting that a lot of code (especially libraries)
either have to support older versions of Python, and so cannot use
f-strings at all, or was written using **locals before f-strings came
along, and hasn't been touched since.

Another case where f-strings don't help is when the template is
dynamically generated.

It may be that there will be less new code written using **locals() but
I don't think that the **locals() trick will disappear any time before
Python 5000.

We've had .format_map since Python 3.2, so why use 
``.format(**locals())`` instead of ``.format_map(locals())``?

___
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 in next Windows 10 update

2019-05-21 Thread MRAB

On 2019-05-21 21:30, Steve Dower wrote:
[snip]

The associated blog post:

https://devblogs.microsoft.com/python/python-in-the-windows-10-may-2019-update/

Here are answers to a few questions that I assume will come up, at least
from this audience that understands the issues better than most:

* if someone had installed Python and put it on PATH with our installer,
this new command *does not* interfere
* if someone had manually modified their own PATH, they *may* see some
interference (but we [Microsoft] decided this was an acceptable risk)
* the Python 3.7 installed from the store will not auto-update to 3.8,
but when 3.8 is released we (Microsoft) will update the redirect to
point at it
* if you pass arguments to the redirect command, it just exits with an
error code - you only get the Store page if you run it without arguments
* once the Store package is installed, the redirect command is replaced
(this required a new feature in the OS). If you install with the regular
installer and update PATH, or active a venv, it will add it *before* the
redirect. So these scenarios should be all good.

I'm happy to answer other questions here. The long-term contact for this
integration is python (at) microsoft.com, which right now will come to me.


Does it behave nicely with py.exe?

Earlier this year I installed an extension in Visual Studio Code for 
programming Arduino. It installed its own version of Python 2.7 (I'm on 
Python 3) and changed the file associations to point to that, thus 
breaking my scripts. (I wasn't keen on its customised icons, either.) I 
was somewhat unhappy at that...

___
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] (no subject)

2019-04-10 Thread MRAB

On 2019-04-10 22:00, Terry Reedy wrote:

On 4/10/2019 7:24 AM, Robert Okadar wrote:

Hi community,

I have developed a tkinter GUI component, Python v3.7. It runs very well in
Linux but seeing a huge performance impact in Windows 10. While in Linux an
almost real-time performance is achieved, in Windows it is slow to an
unusable level.

The code is somewhat stripped down from the original, but the performance
difference is the same anyway. The columns can be resized by clicking on
the column border and dragging it. Resizing works only for the top row (but
it resizes the entire column).
In this demo, all bindings are avoided to exclude influence on the
component performance and thus not included. If you resize the window
(i.e., if you maximize it), you must call the function table.fit() from
IDLE shell.

Does anyone know where is this huge difference in performance coming from?
Can anything be done about it?


For reasons explained by Steve, please send this instead to python-list
https://mail.python.org/mailman/listinfo/python-list
To access python-list as a newsgroup, skip comp.lang.python and use
newsgroup gmane.comp.python.general at news.gmane.org.

I will respond there after testing/verifying and perhaps searching
bugs.python.org for a similar issue.


ttk has Treeview, which can be configured as a table.
___
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] Best way to specify docstrings for member objects

2019-03-19 Thread MRAB

On 2019-03-19 18:55, Raymond Hettinger wrote:

I'm working on ways to make improve help() by giving docstrings to member 
objects.

One way to do it is to wait until after the class definition and then make 
individual, direct assignments to __doc__ attributes.This way widely the 
separates docstrings from their initial __slots__ definition.   Working 
downstream from the class definition feels awkward and doesn't look pretty.

There's another way I would like to propose¹.  The __slots__ definition already 
works with any iterable including a dictionary (the dict values are ignored), 
so we could use the values for the  docstrings.

This keeps all the relevant information in one place (much like we already do 
with property() objects).  This way already works, we just need a few lines in 
pydoc to check to see if a dict if present.  This way also looks pretty and 
doesn't feel awkward.

I've included worked out examples below.  What do you all think about the 
proposal?


[snip]

Thinking ahead, could there ever be anything else that you might want 
also to attach to member objects?


I suppose that if that's ever the case, the value could itself be 
expanded to be a dict, something like this:


__slots__ = {'mu' : {'__doc__': 'Arithmetic mean.'}, 'sigma': 
{'__doc__': 'Standard deviation.'}}


But that could be left to the future...
___
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] Summary of Python tracker Issues

2019-02-28 Thread MRAB

On 2019-02-28 23:54, Glenn Linderman wrote:

On 2/28/2019 2:52 PM, Terry Reedy wrote:

On 2/28/2019 5:38 PM, Glenn Linderman wrote:

On 2/28/2019 2:18 PM, Jonathan Goble wrote:
On Thu, Feb 28, 2019, 5:11 PM Terry Reedy > wrote:


    On 2/28/2019 8:07 AM, Jonathan Goble wrote:
    > On Thu, Feb 28, 2019, 8:02 AM INADA Naoki
    mailto:songofaca...@gmail.com>
    > >>
    wrote:
    >
    >     No stats for last week?
    >
    >
    > Been missing for two weeks actually. I did not receive a 
summary on

    > either the 15th or 22nd.

    Ditto for me.  I get pydev via gmane.  Anyone missing the same 
issues

    get pydev directly by email?


I get direct emails only and stated my observation above. :-)


I confirm and concur with Jonathan's observation, by searching my 
email archive for this group list. So it is not just something about 
his particular email address... except we both do use Google Mail 
services.  I do check my Google SPAM box for the account, and it 
wasn't there either, by recollection (I don't archive the SPAM, but 
delete it ASAP).


Can someone not using a Google email address also confirm?


I effectively did when I said I access via gmane -- as a newsgroup via 
NNTP.  I am sure that the mail server sends directly to news.gmane.org 
rather than through google.


That's a whole different protocol. I don't know all the configurations 
for the server that sends the Summary messages, or how it is handled, 
but you confirm it didn't get to gnane via NNTP, and Jonathan and I 
confirm it didn't get to Google email servers, but neither one really 
confirms that it didn't get to other email servers. Google email is 
definitely different than other email servers.


There seems to be enough evidence that something went wrong somewhere, 
though, and whoever maintains that process should start investigating, 
but it would still be nice to get confirmation from a non-Google email 
recipient whether they did or did not get the Summary messages.


I wonder if there is a way to manually send them, and if the missing two 
weeks of activity can be reported... once the sending problem is 
understood and resolved.


I subscribed at https://mail.python.org/mailman/listinfo/python-dev and 
I don't use Google for email. I didn't receive them either.

___
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] Making PyInterpreterState an opaque type

2019-02-21 Thread MRAB

On 2019-02-21 12:53, Antoine Pitrou wrote:

On Thu, 21 Feb 2019 13:45:05 +0100
Victor Stinner  wrote:

Le jeu. 21 févr. 2019 à 12:36, Antoine Pitrou  a écrit :
>
> On Thu, 21 Feb 2019 12:13:51 +0100
> Victor Stinner  wrote:  
> >

> > Premature optimization is the root of all evil. Most C extensions use
> > premature optimization  
>
> How do you know it's premature?  Some extensions _are_ meant for speed.  


Sorry, I don't ask to stop optimizing C extension. I'm asking to stop
to use low-level C API like PyTuple_GET_ITEM() if the modified code is
the not the performance bottleneck.


As long as some people need that API, you'll have to maintain it
anyway, even if _less_ people use it.  Ingesting lists and tuples as
fast as possible is important for some use cases.  I have worked
personally on some of them (on e.g. Numba or PyArrow).

If I'm working with a dict, the first place I look is PyDict_*, and that 
leads me to PyDict_GetItem. The docs for PyDict_GetItem don't mention 
PyObject_GetItem. Perhaps, if PyObject_GetItem is recommended, it should 
say so, and similarly for other parts of the API.

___
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] Add more SyntaxWarnings?

2019-01-30 Thread MRAB

On 2019-01-30 18:12, Stefan Behnel wrote:

MRAB schrieb am 29.01.19 um 19:55:

On 2019-01-29 13:44, Nick Coghlan wrote:

FWIW, we have pretty decent evidence that error messages don't have to
provide a wonderful explanation on their own in order to be helpful:
they just need to be distinctive enough that a web search will
reliably get you to a page that gives you relevant information.

Pre-seeded answers on Stack Overflow are excellent for handling the
second half of that approach (see [1] for a specific example).
[1]
https://stackoverflow.com/questions/25445439/what-does-syntaxerror-missing-parentheses-in-call-to-print-mean-in-python


I have a vague recollection that a certain computer system (Amiga?) had a
'why' command. If it reported an error, you could type "why" and it would
give you more details.

I suspect that all that was happening was that when the error occurred it
would store the additional details somewhere that the 'why' command would
simply retrieve.


So … are you suggesting to use the webbrowser module inside of the REPL to
look up the exception message of the previously printed stack trace in
stack overflow when a user types "why()"?

No, I was just suggesting it as a possible way of providing newbies with 
more information about an error without annoying more experienced users 
with excessively long messages every time.



I faintly recall someone implementing something in that direction. It's
probably in some package on PyPI.


___
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] Add more SyntaxWarnings?

2019-01-29 Thread MRAB

On 2019-01-29 13:44, Nick Coghlan wrote:

On Tue, 29 Jan 2019 at 14:47, Stephen J. Turnbull
 wrote:

I don't disagree.  I disagree with the conclusion that it's worth the
effort to try to improve all error messages that confuse new users,
because new users (by definition) don't know enough to respond
usefully in many cases.  In those cases, they need to be told what's
going on and why, where more experienced users can figure it out from
their background knowledge of Python semantics.  Embedding a "theory
of operations" note in every error message would be possible, but I
don't think it's a good idea -- it would certainly make the language
more annoying for experienced developers.


FWIW, we have pretty decent evidence that error messages don't have to
provide a wonderful explanation on their own in order to be helpful:
they just need to be distinctive enough that a web search will
reliably get you to a page that gives you relevant information.

Pre-seeded answers on Stack Overflow are excellent for handling the
second half of that approach (see [1] for a specific example).

Cheers,
Nick.

[1] 
https://stackoverflow.com/questions/25445439/what-does-syntaxerror-missing-parentheses-in-call-to-print-mean-in-python

I have a vague recollection that a certain computer system (Amiga?) had 
a 'why' command. If it reported an error, you could type "why" and it 
would give you more details.


I suspect that all that was happening was that when the error occurred 
it would store the additional details somewhere that the 'why' command 
would simply retrieve.

___
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?

2019-01-18 Thread MRAB

On 2019-01-19 00:28, Greg Ewing wrote:

Tim Peters wrote:


The dict itself keeps the objects alive.


Yes, but the idea of a cache is that you're free to flush
things out of it to make room for something else without
breaking anything.

It sounds like MRAB is using ids as weak references,
without the assurance actual weak references give you
that they become invalidated when the refefenced object
goes away,

"Cache" was the wrong word for what it does. I'm not using the id as a 
weak reference.


Sometimes I might want to store a collection of objects and their order 
isn't important. I can add an object to the collection, or remove an 
object from it.


If I used a list, adding would be quick, but removing would require 
searching the list.


By putting them in a dict, keyed by the id, I can remove an object in O(1).

Trust me, I'm not doing anything that's unreliable! (And I _have_ done 
programming in C with the Python API, so I know all about refcounts...) :-)



No such uses care about object addresses, though - just that id(obj)
returns a value usable as a dict key, unique among all reachable
objects at the time `id()` is called.


Yep. In hindsight it was probably a mistake for the docs
to talk about addresses in relation to id() -- it seems to
have given some people unrealistic expectations.


___
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?

2019-01-18 Thread MRAB

On 2019-01-18 23:02, Greg Ewing wrote:

MRAB wrote:
   If I want to cache some objects, I put them in a dict, using the id as
the key. If I wanted to locate an object in a cache and didn't have 
id(), I'd have to do a linear search for it.


That sounds dangerous. An id() is only valid as long as the object
it came from still exists, after which it can get re-used for a different
object. So when an object is flushed from your cache, you would have
to chase down all the places its id is being stored and eliminate them.

Are you sure you couldn't achieve the same thing more safely using
weak references?


I'm not storing the id anywhere else.

I could've used a list for the cache, but then when I wanted to remove 
an object I'd have to search for it, O(n). Using a dict makes it O(1).

___
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?

2019-01-17 Thread MRAB

On 2019-01-18 00:48, Gregory P. Smith wrote:
I've heard that libraries using ctypes, cffi, or cython code of various 
sorts in the real world wild today does abuse the unfortunate side 
effect of CPython's implementation of id(). I don't have specific 
instances of this in mind but trust what I've heard: that it is happening.


id() should never be considered to be the PyObject*.  In as much as code 
shouldn't assume it is running on top of a specific CPython implementation.
If there is a _need_ to get a pointer to a C struct handle referencing a 
CPython C API PyObject, we should make an explicit API for that rather 
than the id() hack.  That way code can be explicit about its need, and 
code that is just doing a funky form of identity tracking without using 
is and is not can continue using id() without triggering regressive 
behavior on VMs that don't have a CPython compatible PyObject under the 
hood by default.


[who uses id() anyways?]


I use it in some of my code.

If I want to cache some objects, I put them in a dict, using the id as 
the key. If I wanted to locate an object in a cache and didn't have 
id(), I'd have to do a linear search for it.

___
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] C API changes

2018-11-26 Thread MRAB

On 2018-11-27 00:08, Larry Hastings wrote:

On 11/23/18 5:15 AM, Armin Rigo wrote:

Also FWIW, my own 2 cents on the topic of changing the C API: let's
entirely drop ``PyObject *`` and instead use more opaque
handles---like a ``PyHandle`` that is defined as a pointer-sized C
type but is not actually directly a pointer.  The main difference this
would make is that the user of the API cannot dereference anything
from the opaque handle, nor directly compare handles with each other
to learn about object identity.  They would work exactly like Windows
handles or POSIX file descriptors.


Why would this be better than simply returning the pointer? Sure, it 
prevents ever dereferencing the pointer and messing with the object, it 
is true.  So naughty people would be prevented from messing with the 
object directly instead of using the API as they should.  But my 
understanding is that the implementation would be slightly 
slower--there'd be all that looking up objects based on handles, and 
managing the handle namespace too.  I'm not convinced the nice-to-have 
of "you can't dereference the pointer anymore" is worth this runtime 
overhead.


Or maybe you have something pretty cheap in mind, e.g. "handle = pointer 
^ 49"?  Or even "handle = pointer ^ (random odd number picked at 
startup)" to punish the extra-naughty?


An advantage would be that objects could be moved to reduce memory 
fragmentation.

___
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] Standardize error message for non-pickleable types

2018-10-30 Thread MRAB

On 2018-10-30 08:12, Serhiy Storchaka wrote:

29.10.18 23:17, MRAB пише:

1. If you're pickling, then saying "pickle" is more helpful.

2. In English the usual long form is "cannot". Error messages tend to 
avoid abbreviations, and also tend to have lowercase after the colon, e.g.:


     "ZeroDivisionError: division by zero"

     "ValueError: invalid literal for int() with base 10: 'foo'"

3. If it's failing on an object (singular), then it's clearer to say 
"object".


4. Articles tend to be omitted.

5. Error messages tend to have quotes around the type name.

Therefore, my preference is for:

     "cannot pickle 'XXX' object"


Thank you Matthew, I'll use your variant.

Will something change the fact that in all these cases the pickling will
be failed not just for specific object, but for all instances of the
specified type?

Well, the other examples you gave did not say explicitly that all 
instances of that type would fail.


If you look at what 'hash' says:

>>> hash(())
3527539
>>> hash(([]))
Traceback (most recent call last):
  File "", line 1, in 
TypeError: unhashable type: 'list'

that would suggest "TypeError: unpicklable type: 'list'", but I'm not 
sure I'd like too much of "unpicklable", "unmarshallable", 
"unserializable", etc. :-)

___
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] Standardize error message for non-pickleable types

2018-10-29 Thread MRAB

On 2018-10-29 22:21, Steven D'Aprano wrote:

On Mon, Oct 29, 2018 at 08:51:34PM +0100, Victor Stinner wrote:

Le lun. 29 oct. 2018 à 20:42, Serhiy Storchaka  a écrit :
> 1. "pickle" or "serialize"?

serialize


-1

Serializing is more general; pickle is merely one form of serializing:

https://en.wikipedia.org/wiki/Comparison_of_data_serialization_formats

When practical, error messages should be more specific, not less. We
don't say "arithmetic operation by zero" for division by zero errors, we
specify which arithmetic operation failed.

Unlike most serialization formats, "pickle" is both a noun (the name of
the format) and the verb to convert to that format.


And if you're marshalling, then saying "marshal" is more helpful.
___
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] Standardize error message for non-pickleable types

2018-10-29 Thread MRAB

On 2018-10-29 19:38, Serhiy Storchaka wrote:

When you try to to pickle or copy a non-pickleable object, you will get
an error. In most cases this will be a TypeError with one of few
similar, but different variants:

"can't pickle XXX objects" (default)
"Cannot serialize XXX object" (socket, BZ2Compressor, BZ2Decompressor)
"can not serialize a 'XXX' object" (buffered files in _pyio)
"cannot serialize 'XXX' object" (FileIO, TextWrapperIO, WinConsoleIO,
buffered files in _io, LZMACompressor, LZMADecompressor)
"cannot serialize {} object" (proposed for SSLContext)

Perhaps some of them where added without deep thinking and then were
replicated in different places. I'm going to replace all of them with a
standardized error message. But I'm unsure what variant is better.

1. "pickle" or "serialize"?

2. "can't", "Cannot", "can not" or "cannot"?

3. "object" or "objects"?

4. Use the "a" article or not?

5. Use quotes around type name or not?

Please help me to choose the best variant.


1. If you're pickling, then saying "pickle" is more helpful.

2. In English the usual long form is "cannot". Error messages tend to 
avoid abbreviations, and also tend to have lowercase after the colon, e.g.:


"ZeroDivisionError: division by zero"

"ValueError: invalid literal for int() with base 10: 'foo'"

3. If it's failing on an object (singular), then it's clearer to say 
"object".


4. Articles tend to be omitted.

5. Error messages tend to have quotes around the type name.

Therefore, my preference is for:

"cannot pickle 'XXX' object"
___
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] LibSSH Vulnerability

2018-10-18 Thread MRAB

I wondered if any of you have heard of this:

Hacker: I'm logged in. New LibSSH Vulnerability: OK! I believe you.
https://www.bleepingcomputer.com/news/security/hacker-im-logged-in-new-libssh-vulnerability-ok-i-believe-you/
___
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


  1   2   3   4   5   >