[Python-Dev] Re: Making code object APIs unstable

2021-09-07 Thread Stefan Behnel 

Guido van Rossum schrieb am 07.09.21 um 00:44:

In addition, I just heard from the SC that they've approved the exception.
So we will remove these two APIs from 3.11 without deprecation.
Erm, hang on – when I wrote that I'm fine with *changing* them, I wasn't 
thinking of actually *removing* them. At least not both. PyCode_NewEmpty() 
isn't a good replacement since it takes low level arguments … char* instead 
of Python strings. It's good for the simple use case that it was written 
for (and Cython already uses it for that), but not so great for anything 
beyond that.


What I could try is to create only a single dummy code object and then 
always call .replace() on it to create new ones. But that seems hackish and 
requires managing yet another bit of global state across static and 
generated code parts.


I could also switch to _PyCode_New(), though it's not exactly what I would 
call an attractive option, both for usability reasons and its future API 
stability. (Cython also still generates C89 code, i.e. no partial struct 
initialisations.)


Any suggestions?

Stefan

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

[Python-Dev] Re: Making code object APIs unstable

2021-09-07 Thread Guido van Rossum 
On Tue, Sep 7, 2021 at 10:00 AM Stefan Behnel  wrote:

> Guido van Rossum schrieb am 07.09.21 um 00:44:
> > In addition, I just heard from the SC that they've approved the
> exception.
> > So we will remove these two APIs from 3.11 without deprecation.
>


> Erm, hang on – when I wrote that I'm fine with *changing* them, I wasn't
> thinking of actually *removing* them. At least not both. PyCode_NewEmpty()
> isn't a good replacement since it takes low level arguments … char*
> instead
> of Python strings. It's good for the simple use case that it was written
> for (and Cython already uses it for that), but not so great for anything
> beyond that.
>

Is the issue that you want to specify a few additional simple arguments, or
that you already have unicode objects and you don't want to have them
converted back to char * (which will then be converted to new unicode
objects by PyCode_NewEmpty)?


> What I could try is to create only a single dummy code object and then
> always call .replace() on it to create new ones. But that seems hackish
> and
> requires managing yet another bit of global state across static and
> generated code parts.
>

I can't argue with the need for an extra bit of global state, but to me,
calling .replace() is not hackish, it's the best way to create new code
objects -- it works for older Python versions and will keep working in the
future.


> I could also switch to _PyCode_New(), though it's not exactly what I would
> call an attractive option, both for usability reasons and its future API
> stability. (Cython also still generates C89 code, i.e. no partial struct
> initialisations.)
>

That's too bad. With the new struct initializations it's actually more
usable and more stable going forward.


> Any suggestions?
>
> Stefan
>
> ___
> Python-Dev mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/[email protected]/message/B6WFHGVAASF4MFUMPIHBZEUCPXVANU7D/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

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

[Python-Dev] [RELEASE] Python 3.10.0rc2 is available

2021-09-07 Thread Pablo Galindo Salgado 
Python 3.10 is one month away, can you believe it? This snake is still
trying to bite as it has been an interesting day of fighting fires, release
blockers, and a bunch of late bugs but your friendly release team always
delivers :)

You can get this new release while is still fresh here:

https://www.python.org/downloads/release/python-3100rc2/

This is the second release candidate of Python 3.10

This release, **3.10.0rc2** , is the last preview before the final release
of Python 3.10.0 on 2021-10-04. Entering the release candidate phase, only
reviewed code changes which are clear bug fixes are allowed between release
candidates and the final release. There will be no ABI changes from this
point forward in the 3.10 series and the goal is that there will be as few
code changes as possible.

*The next release will be the final release of Python 3.10.0, which is
currently scheduled for Monday, 2021-10-04.*

Call to action
⚠️⚠️⚠️⚠️⚠️⚠️⚠️
*The 3.10 branch is now accepting changes for 3.10.**1*. To maximize
stability, the final release will be cut from the v3.10.0rc2 tag. If you
need the release manager (me) to cherry-pick any critical fixes, mark
issues as release blockers, and/or add me as a reviewer on a critical
backport PR on GitHub. To see which changes are currently cherry-picked for
inclusion in 3.10.0, look at the short-lived branch-v3.10.0
https://github.com/python/cpython/tree/branch-v3.10.0 on GitHub.
⚠️⚠️⚠️⚠️⚠️⚠️⚠️

*Core developers: all eyes on the docs now*

   - Are all your changes properly documented?
   - Did you notice other changes you know of to have insufficient
   documentation?


*Community members*
We strongly encourage maintainers of third-party Python projects to prepare
their projects for 3.10 compatibilities during this phase. As always,
report any issues to [the Python bug tracker ](https://bugs.python.org/).

Please keep in mind that this is a preview release and its use is **not**
recommended for production environments.

And now for something completely different
Maxwell's demon is a thought experiment that would hypothetically violate
the second law of thermodynamics. It was proposed by the physicist James
Clerk Maxwell in 1867. In the thought experiment, a demon controls a small
massless door between two chambers of gas. As individual gas molecules (or
atoms) approach the door, the demon quickly opens and closes the door to
allow only fast-moving molecules to pass through in one direction, and only
slow-moving molecules to pass through in the other. Because the kinetic
temperature of a gas depends on the velocities of its constituent
molecules, the demon's actions cause one chamber to warm up and the other
to cool down. This would decrease the total entropy of the two gases,
without applying any work, thereby violating the second law of
thermodynamics.

We hope you enjoy those new releases!
Thanks to all of the many volunteers who help make Python Development and
these releases possible! Please consider supporting our efforts by
volunteering yourself or through organization contributions to the Python
Software Foundation.

Regards from a plane going to Malaga,

Your friendly release team,
Pablo Galindo @pablogsal
Ned Deily @nad
Steve Dower @steve.dower
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/PKIM4YATUDGXNRD36QYXMDVJX5RJXP2J/
Code of Conduct: http://python.org/psf/codeofconduct/

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

2021-09-07 Thread Barry Warsaw 
I’m finally getting back around to this thread.  I’d like to see some 
resolution to the bchr/fromint question, since it seems like that’s the last 
thing holding up approval of the PEP.  And the PEP has other useful additions 
that I’d like to see in Python 3.11.

On Aug 22, 2021, at 16:08, Guido van Rossum  wrote:
> 
> Hm, I don’t think the major use for bchr() will be with a constant.

Perhaps.  I think Greg’s idea has merit anyway, but it doesn’t *have* to be 
tied to PEP 467.

I think Nick is on board with bytes.fromint() and no bchr(), and my sense of 
the sentiment here is that this would be an acceptable resolution for most 
folks.  Ethan, can you reconsider?

Cheers,
-Barry



signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/JC2V7L7OAZTYNQ7FJZSEXCFAK562XEHG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: [Python-ideas] Re: open functions in dbm submodule need to support path-like object

2021-09-07 Thread David Mertz, Ph.D. 
I attempted to do this today, as my first actual contribution to CPython
itself.  I think the prior attempt went down a wrong path, which is why
neither PR could actually pass tests.

I've been looking at `posixmodule.c` for comparison, specifically.  The key
thing, I believe, is not to use `PyObject *filename` in the
`dpmopen_impl()` calls at all, but rather `path_t *path`.  I tried some
absolutely crude instrumentation to see why the `PyOS_FSPath` macro and the
rest wasn't doing what it seems like it should (i.e. sticking `printf()`s
in the .c files).  Eventually I realized that argument clinic is stopping
me from even getting to the body of the function when `filename` was a
PosixPath, so anything that PyOS_FSPath does is moot.

I think in the end the new code should be even simpler than the main (3.11)
branch.  All I really need to do with a `path_t` is be able to call:

PyObject *self = newgdbmobject(state, name, iflags, mode);

That is, `name` is simply the filename as char* (the other parameters are
independent of the path-like issue).

Does anyone have pointers to an example or documentation about doing this?
The patterns in posixmodule.c are suggestive, but I'm not sure of the
missing pieces.

Also, I copied the typedef for path_t from posixmodule.c to both
`_dbmmodule.c` and `_gdbmmodule.c`.  I know that's also going to be wrong,
and it should be pulled into an .h file.  Any idea about which one?
`posixmodule.h` seems like a possibility, but then I'd need to repeat it in
`winreparse.h`.  Maybe a new name?



On Tue, Sep 7, 2021 at 1:11 PM Guido van Rossum  wrote:

> If someone posted a Pull Request that added this, it would be looked upon
> favorably I'm sure.
>
> On Tue, Sep 7, 2021 at 8:31 AM Christopher Barker 
> wrote:
>
>> it looks like this as had a BPO for over a year:
>>
>> https://bugs.python.org/issue40563
>>
>> I suggest pinging that (and maybe python-dev) to see what's up.
>>
>> NOTE: first check 3.10 :-)
>>
>> -CHB
>>
>>
>> On Tue, Sep 7, 2021 at 5:05 AM Evan Greenup via Python-ideas <
>> [email protected]> wrote:
>>
>>> Currently, in Python 3.9, `dbm.open()`, `dbm.gnu.open()` and
>>> `dbm.ndbm.open()` doesn't support path-like object, class defined in
>>> `pathlib`.
>>>
>>> It would be nice to add support with it.
>>>
>>>
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/QSS5SCSK2ZXNBQSGYIRSED6UMWB32PAQ/
Code of Conduct: http://python.org/psf/codeofconduct/

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

2021-09-07 Thread Steven D'Aprano 
On Tue, Sep 07, 2021 at 08:09:33PM -0700, Barry Warsaw wrote:

> I think Nick is on board with bytes.fromint() and no bchr(), and my 
> sense of the sentiment here is that this would be an acceptable 
> resolution for most folks.  Ethan, can you reconsider?

I haven't been completely keeping up with the entire thread, so 
apologies if this has already been covered. I assume that the idea is 
that bytes.fromint should return a single byte, equivalent to chr() 
returning a single character.

To me, it sounds like should be the opposite of int.from_bytes.

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

If that's not the API being suggested, that's going to be confusing.

How about bytes.bchr()?

bytes.bchr(n) --> a single byte

bytes.from_int(n, byteorder)  --> one or more bytes

Personally, I think I would use the one or more bytes version more then 
the single bchr version, so if we only had one, I vote for that.


-- 
Steve
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/4BZ6MTOZM23UXMIUCMHVH3QXCN2ICOJ2/
Code of Conduct: http://python.org/psf/codeofconduct/