[Python-Dev] Re: A proposal to modify `None` so that it hashes to a constant

On Thu, 1 Dec 2022 at 06:56, Chris Angelico wrote: > > On Thu, 1 Dec 2022 at 17:26, Yoni Lavi wrote: > > > > So it's not like it's even possible to require this generally for all > > objects. > > Well, I mean, in theory you could require that objects whose hash > isn't otherwise defined get give

[Python-Dev] Re: A proposal to modify `None` so that it hashes to a constant

On Tue, 29 Nov 2022 at 23:46, Steven D'Aprano wrote: > > On Tue, Nov 29, 2022 at 08:51:09PM -, Yoni Lavi wrote: > > > It does make your argument invalid though, since it's based on this > > assumption that I was asking for a requirement on iteration order > > (e.g. like dict's iteration order

[Python-Dev] Re: A proposal to modify `None` so that it hashes to a constant

On Tue, 29 Nov 2022 at 01:33, Steven D'Aprano wrote: > > On Mon, Nov 28, 2022 at 11:13:34PM +0000, Oscar Benjamin wrote: > > On Mon, 28 Nov 2022 at 22:56, Brett Cannon wrote: > > As I understand it, we could make sets ordered, but only at the cost of > space (much mo

[Python-Dev] Re: A proposal to modify `None` so that it hashes to a constant

On Mon, 28 Nov 2022 at 22:56, Brett Cannon wrote: > > On Sun, Nov 27, 2022 at 11:36 AM Yoni Lavi wrote: >> >> All it takes is for your program to compute a set somewhere with affected >> keys, and iterate on it - and determinism is lost. > > That's actually by design. Sets are not meant to be de

[Python-Dev] Re: Increase of Spammy PRs and PR reviews

On Sun, 30 Jan 2022 at 20:36, Steven D'Aprano wrote: > > On Sun, Jan 30, 2022 at 08:36:43AM -0800, Jelle Zijlstra wrote: > > > Agree, the count of 1.6k open PRs is not a good look for new contributors. > > How does that compare to other comparable open source projects? How it compares is a separa

[Python-Dev] Re: The current state of typing PEPs

On Wed, 1 Dec 2021 at 12:12, Sebastian Rittau wrote: > > Am 30.11.21 um 13:39 schrieb Oscar Benjamin: > >> Others have mentioned the pressure on libraries to adopt typing and >> I've certainly noticed this with SymPy. I think type hints could be >> good for Sym

[Python-Dev] Re: Expectations of typing (was: The current state of typing PEPs)

On Tue, 30 Nov 2021 at 23:37, Guido van Rossum wrote: > > We should definitely push back on zealous new converts to typing who insist > that everything should be annotated. But we should also recognize that even > in their current, far from perfect state, type annotations can provide a lot > of

[Python-Dev] Re: The current state of typing PEPs

On Tue, 30 Nov 2021 at 09:23, Paul Moore wrote: > > On Tue, 30 Nov 2021 at 02:52, Steve Dower wrote: > > > > THAT'S the kind of thing that also has been happening with typing, and > > why some of us feel the need to publicly re-state things that are all > > agreed upon within this group, but are

[Python-Dev] Re: The current state of typing PEPs

On Thu, 25 Nov 2021 at 15:16, Stephen J. Turnbull wrote: > > Executive summary: > > The typing-suspicious crowd has a valid complaint about PEPs 563 and > 649, but it's not that they weren't warned. > > Christopher Barker writes: > > > Annotations can be, and are, used for other things than "typi

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

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 kn

[Python-Dev] Re: IRC #python-dev channel is now on Libera Chat (bye bye Freenode)

On Thu, 27 May 2021 at 00:52, Dan Stromberg wrote: > > > On Wed, May 26, 2021 at 4:25 PM Greg Ewing > wrote: >> >> > On Wed, May 26, 2021 at 8:55 AM Ammar Askar > > > wrote: >> > >> > most >> > recently if your topic mentioned libera.chat, the new freenode ow

[Python-Dev] Re: PEP 659: Specializing Adaptive Interpreter

On Thu, 20 May 2021 at 04:58, Terry Reedy wrote: > > On 5/13/2021 4:18 AM, Mark Shannon wrote: > > > If a program does 95% of its work in a C++ library and 5% in Python, it > > can easily spend the majority of its time in Python because CPython is a > > lot slower than C++ (in general). > > I beli

[Python-Dev] Re: In support of PEP 649

On Fri, 16 Apr 2021 at 01:13, Guido van Rossum wrote: > > On Thu, Apr 15, 2021 at 16:48 Christopher Barker wrote: >> >> And as I noted in my last post — many folks have not been paying attention >> to the typing discussions because they didn’t realize it concerned them. > > It seems a little dis

[Python-Dev] Re: Request for comments on final version of PEP 653 (Precise Semantics for Pattern Matching)

On Tue, 30 Mar 2021 at 17:32, Brandt Bucher wrote: Hi Brandt, > > Which requires the sympy class `Symbol` to "self" match. For `sympy` to > > support this pattern with PEP 634 is possible, but a bit tricky. With this > > PEP it can be implemented very easily. > > Maybe I'm missing something, b

[Python-Dev] Re: Request for comments on final version of PEP 653 (Precise Semantics for Pattern Matching)

On Sat, 27 Mar 2021 at 13:40, Mark Shannon wrote: > Hi Mark, Thanks for putting this together. > As the 3.10 beta is not so far away, I've cut down PEP 653 down to the > minimum needed for 3.10. The extensions will have to wait for 3.11. > > The essence of the PEP is now that: > > 1. The semant

[Python-Dev] Re: Have virtual environments led to neglect of the actual environment?

On Mon, 1 Mar 2021 at 00:13, Eryk Sun wrote: > > On 2/28/21, Oscar Benjamin wrote: > > > > - It is possible to configure a default version (although I think you > > have to do it with an environment variable) > > The py launcher in Windows supports a "py.ini&q

[Python-Dev] Re: Have virtual environments led to neglect of the actual environment?

On Sun, 28 Feb 2021 at 07:04, Stephen J. Turnbull wrote: > > Jim J. Jewett writes: > > > > which file am I actually running? > > > which interpreter am I actually running? > > > how do I tell the computer to use a different interpreter? > > > > If you need to care about any of these, then the

[Python-Dev] Re: Have virtual environments led to neglect of the actual environment?

On Sat, 27 Feb 2021 at 11:04, Paul Moore wrote: > > On Sat, 27 Feb 2021 at 01:08, Oscar Benjamin > wrote: > > > > The other point though is that it doesn't need to be like this. If the > > issue was just installing Python and then setting up your PATH then >

[Python-Dev] Re: Have virtual environments led to neglect of the actual environment?

On Fri, 26 Feb 2021 at 23:06, Jim J. Jewett wrote: > > I think his point is that most of his students (economics or business, rather > than comp sci) will never need to use Perl or C or Java. Python is friendly > enough to be useful, but this is still a major pain point. Thanks Jim, that is th

[Python-Dev] Re: Have virtual environments led to neglect of the actual environment?

On Fri, 26 Feb 2021 at 09:07, Steven D'Aprano wrote: > > On Fri, Feb 26, 2021 at 11:41:56AM +0900, Stephen J. Turnbull wrote: > > Mike Miller writes: > > > > > "sys-admin" is a bit of an overstatement in my phrasing. The core > > > is that you need to understand how a PATH works and be able to

[Python-Dev] Re: PEP 653: Precise Semantics for Pattern Matching

On Fri, 19 Feb 2021 at 15:41, Tobias Kohn wrote: > > Hi Mark, > > Thank you for your proposal to try and have more precise semantics for > pattern matching. Of course, the proposal primarily introduces a new and > extended protocol for pattern matching, upon which the 'semantics' is then > bas

[Python-Dev] Re: PEP 653: Precise Semantics for Pattern Matching

On Fri, 19 Feb 2021 at 16:27, Tobias Kohn wrote: > > Quoting Oscar Benjamin : > > > I'm not entirely sure but I think that with PEP 653 you can implement this > > like: > > > > def __deconstruct__(obj): > > if obj.step != 1: > &

[Python-Dev] Re: PEP 653: Precise Semantics for Pattern Matching

On Thu, 18 Feb 2021 at 17:35, Brandt Bucher wrote: > > Thanks for taking the time to work on this, Mark. Yes, thanks Mark. I'm not sure I've fully understood the PEP yet but I can see some parts that I definitely like. > I fear this is at the expense of most simple classes, which currently "just

[Python-Dev] Re: Python standardization

On Fri, Feb 12, 2021, at 12:33, Dan Stromberg wrote: > > What would it take to create an ANSI, ECMA and/or ISO standard for Python? > > It seems to have really helped C. That confuses cause and effect. C was standardized because there sprung up hundreds of vaguely compatible implementations—a

[Python-Dev] Re: Concerns about PEP 634

On Sat, 6 Feb 2021 at 19:54, Daniel Moisset wrote: > > Hi Mark, > > I think some of these issues have already been raised and replied (even if no > agreement has been reached). but this is a good summary, so let me reply with > a summary of responses for this. > > On Sat, 6 Feb 2021 at 15:51, Ma

[Python-Dev] Re: [python-committers] Performance benchmarks for 3.9

On Wed, 14 Oct 2020 at 19:12, Ivan Pozdeev via Python-Dev wrote: > > > On 14.10.2020 17:04, M.-A. Lemburg wrote: > > On 14.10.2020 16:00, Pablo Galindo Salgado wrote: > >>> Would it be possible to get the data for older runs back, so that > >> it's easier to find the changes which caused the slo

[Python-Dev] Re: Hygenic macros PEP.

On Tue, Sep 15, 2020, at 23:54, Guido van Rossum wrote: > On Tue, Sep 15, 2020 at 7:31 PM Benjamin Peterson wrote: > > On Tue, Sep 15, 2020, at 20:10, Greg Ewing wrote: > > > Maybe the PEP should propose an AST of its own, which would initially > > > be a third th

[Python-Dev] Re: Hygenic macros PEP.

On Tue, Sep 15, 2020, at 20:10, Greg Ewing wrote: > On 16/09/20 12:37 pm, Guido van Rossum wrote: > > IMO if we were to standardize the AST for times immemorial this would > > have to be a separate PEP. > > Perhaps, but a stable AST seems to be a prerequisite for this kind > of feature. Prefer

[Python-Dev] Re: Taking over xxlimited for PEP 630

On Tue, Sep 8, 2020, at 08:13, Petr Viktorin wrote: > Hello, > The "xxlimited" module (Modules/xxlimited.c) was added as part of PEP > 384 (Defining a Stable ABI), and is undocumented. As far as I can tell, > it was added partly to test the stable ABI, and partly as an example of > how to wri

[Python-Dev] Re: PEP 387: backwards compatibility policy

On Mon, Jul 20, 2020, at 13:50, Brett Cannon wrote: > The SC has chosen to accept PEP 387! https://www.python.org/dev/peps/pep-0387/ Thank you, steering council! I am particularly grateful to Brett for pushing this PEP, in its eleventh year of existence, over the finish line. _

[Python-Dev] Re: PEP 622 and variadic positional-only args

On Thu, 16 Jul 2020 at 02:09, Guido van Rossum wrote: > > On Wed, Jul 15, 2020 at 4:41 PM Oscar Benjamin > wrote: >> >> I've taken a look through PEP 622 and I've been thinking about how it >> could be used with sympy. >> >> In principle case/m

[Python-Dev] PEP 622 and variadic positional-only args

I've taken a look through PEP 622 and I've been thinking about how it could be used with sympy. In principle case/match and destructuring should be useful for sympy because sympy has a class Basic which defines a common structure for ~1000 subclasses. There are a lot of places where it is necessar

[Python-Dev] [RELEASE] Python 2.7.18, the end of an era

hased Python 2 out of their archives. Users migrated hundreds of millions of lines of code, developed porting guides, and kept Python 2 in their brain while Python 3 gained 10 years of improvements. Finally, thank you to GvR for creating Python 0.9, 1, 2, and 3.

[Python-Dev] Re: Python2 as 𝑣 → 𝑒

The relevant parties are aware. On Sat, Apr 11, 2020, at 17:17, Mike Miller wrote: > > Unless I've read something wrong, it looks like the final Python 2 release > (2.7.18) should approximate the math constant e: > > >>> import math > >>> math.e > 2.718281828459045 > > Aka: > >

[Python-Dev] [RELEASE] Python 2.7.18 release candidate 1

us know if there are any critical problems at https://bugs.python.org/ (This is the last chance!) All the best, Benjamin ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https

[Python-Dev] Re: The Python 2 death march

On Fri, Mar 27, 2020, at 11:49, Sumana Harihareswara wrote: > Benjamin: now that PyCon 2020 has been cancelled, are you considering > releasing 2.7.18 slightly earlier? The plan is to follow the dates in PEP 373. ___ Python-Dev mailin

[Python-Dev] Re: Maintenance of multiprocessing module: there are a few stalled issues/patches

On Wed, Feb 12, 2020, at 08:22, mailer@app.tempr.email wrote: > I've just been looking through the multiprocessing module and open > issues and wondered why there were some small bugs/patches not being > fixed/merged. Is this the "normal" patch cycle? Does it take years for > bugs to get fixe

[Python-Dev] Re: PEP proposal to limit various aspects of a Python program to one million.

On Tue, 10 Dec 2019 at 00:00, Steven D'Aprano wrote: > > On Sat, Dec 07, 2019 at 07:37:58PM +0000, Oscar Benjamin wrote: > > > I recently hit on a situation that created a one million line code file: > > https://github.com/pytest-dev/pytest/issues/4406#issuecomment-4396

[Python-Dev] Re: PEP proposal to limit various aspects of a Python program to one million.

On Mon, 9 Dec 2019 at 14:10, Mark Shannon wrote: > On 07/12/2019 7:37 pm, Oscar Benjamin wrote: > > On Sat, 7 Dec 2019 at 06:29, Steven D'Aprano wrote: > >> > >> A million seems reasonable for lines of source code, if we're prepared > >> to tell peop

[Python-Dev] Re: PEP proposal to limit various aspects of a Python program to one million.

On Sat, 7 Dec 2019 at 06:29, Steven D'Aprano wrote: > > A million seems reasonable for lines of source code, if we're prepared > to tell people using machine generated code to split their humongous .py > files into multiple scripts. A small imposition on a small subset of > Python users, for the b

[Python-Dev] Re: PEP proposal to limit various aspects of a Python program to one million.

On Wed, 4 Dec 2019 at 05:41, Chris Angelico wrote: > > On Wed, Dec 4, 2019 at 3:16 PM Steven D'Aprano wrote: > > > > On Wed, Dec 04, 2019 at 01:47:53PM +1100, Chris Angelico wrote: > > > > > Integer sizes are a classic example of this. Is it acceptable to limit > > > your integers to 2^16? 2^32?

[Python-Dev] Re: Fun with Python 3.8 and Qt

It's known: https://bugs.python.org/issue38007 On Mon, Oct 21, 2019, at 20:11, Kacvinsky, Tom wrote: > Today I discovered the this struct > > typedef struct{ > const char* name; > int basicsize; > int itemsize; > unsigned int flags; > PyType_Slot *slots; /* terminated by slot=

[Python-Dev] [RELEASE] Python 2.7.17

nates 2.7.17 as the penultimate Python 2.7 release. So, be aware that the upstream demise of Python 2 is not far away. For the time being, bugs may be reported to https://bugs.python.org. See you soon for The End, Benjamin ___ Python-Dev mailing list -- p

[Python-Dev] [RELEASE] Python 2.7.17 release candidate 1

release schedule, calls for 2.7.17 to be the penultimate bug fix release of the Python 2.7 series. Time for Python 2 is running low! Regards, Benjamin 2.7 release manager ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to

[Python-Dev] Re: The Python 2 death march

On Wed, Sep 25, 2019, at 17:25, Rob Cliffe via Python-Dev wrote: > > I additionally share the bemusement of some other commentators on this > > thread to the idea of Python 2 "support", which is not something ever > > promised to Python 2 (or 3) users by CPython core developers. Essentially, >

[Python-Dev] Re: The Python 2 death march

On Wed, Sep 18, 2019, at 19:23, Kyle Stanley wrote: > Benjamin, what are you thoughts on usage of the "needs backport to 2.7" > label? For most of the PRs I've reviewed I tend to avoid adding it > myself, but I've seen it used periodically. It seems to be used rat

[Python-Dev] Re: The Python 2 death march

On Fri, Sep 13, 2019, at 18:18, Sumana Harihareswara wrote: > Hi. I've joined python-dev to participate in this thread (I don't have > email delivery turned on; I'll be checking back via the web). sorry :) > > Benjamin, I am sorry that I didn't check in with

[Python-Dev] Re: The Python 2 death march

On Tue, Sep 10, 2019, at 15:54, Ned Batchelder wrote: > Maybe I'm not involved enough in the release process, but this seems > confusing to me.  On the same day that the PSF put up a page about the > 1/1/2020 date, we choose April 2020 as the last release?  Why?  I > thought the point was to sav

[Python-Dev] The Python 2 death march

sunset-python-2/ Regards, Benjamin ___ 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

Re: [Python-Dev] Python in next Windows 10 update

On Tue, 21 May 2019 at 21:32, Steve Dower wrote: > > In the next Windows 10 update that starts rolling out today, we > (Microsoft) have added "python.exe" and "python3.exe" commands that are > installed on PATH *by default* and will open the Microsoft Store at the > page where we (Python core team

Re: [Python-Dev] Farewell, Python 3.4

rs of the release team that worked on > Python 3.4: > > > Georg Brandl > > > Julien Palard > > > Martin von Löwis > > > Ned Deily > > > Steve Dower > > > Terry Reedy > > > and all the engineers of the Python infrastructure team. >

Re: [Python-Dev] [RELEASE] Python 2.7.16

On Tue, Mar 5, 2019, at 03:18, Miro Hrončok wrote: > On 04. 03. 19 4:30, Benjamin Peterson wrote: > > Hello all, > > I'm pleased to announce the immediate availability of Python 2.7.16 for > > download at https://www.python.org/downloads/release/python-2716/. > >

[Python-Dev] [RELEASE] Python 2.7.16

gelog for a full list of changes: https://raw.githubusercontent.com/python/cpython/v2.7.16/Misc/NEWS.d/2.7.16rc1.rst Please report any bugs to https://bugs.python.org/. Regards, Benjamin 2.7 release manager (on behalf of all Python 2.7's co

[Python-Dev] [RELEASE] Python 2.7.16 release candidate 1

ng to plan, Python 2.7.16 final will be released on March 2. All the best, Benjamin ___ 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/ar

[Python-Dev] 2.7.16 release dates

Greetings, I've set the dates for the 2.7.16 release in PEP 373. The release candidate will happen on February 16 with a final release 2 weeks later on March 2 if all goes well. Servus, Benjamin ___ Python-Dev mailing list Python-Dev@python.org

Re: [Python-Dev] Standard library vs Standard distribution?

On Fri, 30 Nov 2018 at 00:17, Steven D'Aprano wrote: > > On Thu, Nov 29, 2018 at 01:30:28PM -0800, Nathaniel Smith wrote: > > [...] > > > > https://anaconda.com/ > > > > https://www.activestate.com/products/activepython/ > > > > http://winpython.github.io/ > > > > http://python-xy.github.io/ > > >

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

On Thu, Nov 29, 2018, at 08:45, Antoine Pitrou wrote: > > Le 29/11/2018 à 15:36, Benjamin Peterson a écrit : > >> > >> I'd like to point the discussion is asymmetric here. > >> > >> On the one hand, people who don't have access to PyPI would

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

On Wed, Nov 28, 2018, at 15:27, Steven D'Aprano wrote: > On Wed, Nov 28, 2018 at 10:43:04AM -0800, Gregory P. Smith wrote: > > > PyPI makes getting more algorithms easy. > > Can we please stop over-generalising like this? PyPI makes getting > more algorithms easy for *SOME* people. (Sorry for

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

On Thu, Nov 29, 2018, at 04:54, Antoine Pitrou wrote: > On Thu, 29 Nov 2018 09:52:29 + > Paul Moore wrote: > > [This is getting off-topic, so I'll limit my comments to this one email] > > > > On Thu, 29 Nov 2018 at 03:17, Brett Cannon wrote: > > > We have never really had a discussion abo

Re: [Python-Dev] Missing functions [Was: Re: Experiment an opt-in new C API for Python? (leave current API unchanged)]

On Wed, Nov 21, 2018, at 06:53, Matěj Cepl wrote: > On 2018-11-19, 11:59 GMT, Stefan Krah wrote: > > In practice people desperately *have* to use whatever is > > there, including functions with underscores that are not even > > officially in the C-API. > > Yes, there are some functions which e

Re: [Python-Dev] Rename Include/internals/ to Include/pycore/

On Mon, Oct 29, 2018, at 05:38, Victor Stinner wrote: > Le lun. 29 oct. 2018 à 06:32, Benjamin Peterson a écrit > : > > > My overall approach is to make sure that we don't leak functions by > > > mistakes into the public API or into the stable API anymore. For &g

Re: [Python-Dev] Rename Include/internals/ to Include/pycore/

On Sun, Oct 28, 2018, at 14:30, Victor Stinner wrote: > Le dim. 28 oct. 2018 à 21:50, Benjamin Peterson a écrit > : > > I don't think more or less API should be magically included based on > > whether Py_BUILD_CORE is defined or not. If we want to have private > &g

Re: [Python-Dev] Rename Include/internals/ to Include/pycore/

On Sun, Oct 28, 2018, at 09:20, Victor Stinner wrote: > Hi, > > Python C API has no strict separation between the 3 levels of API: > > * core: Py_BUILD_CORE define > * stable: Py_LIMITED_API define (it has a value) > * regular: no define > > IMHO the current design of header files is done bac

Re: [Python-Dev] Arbitrary non-identifier string keys when using **kwargs

On Tue, Oct 9, 2018, at 17:14, Barry Warsaw wrote: > On Oct 9, 2018, at 16:21, Steven D'Aprano wrote: > > > > On Tue, Oct 09, 2018 at 10:26:50AM -0700, Guido van Rossum wrote: > >> My feeling is that limiting it to strings is fine, but checking those > >> strings for resembling identifiers is p

Re: [Python-Dev] Should assert continue to do a LOAD_GLOBAL on AssertionError?

On Wed, Oct 3, 2018, at 08:59, Steven D'Aprano wrote: > On the bug tracker, there's a discussion about the current behaviour of > the assert statement, where shadowing AssertionError will change the > behaviour of the assertion. > > https://bugs.python.org/issue34880 > > Currently, assert do

Re: [Python-Dev] LDLAST variable in configure.ac

On Mon, Oct 1, 2018, at 12:12, Michael Felt wrote: > Hi all, > > Before I submit a patch to increase the default MAXDATA setting for AIX > when in 32-bit mode - I want to know if I can put this LDFLAG setting in > LDLAST, or if I should introduce a new AC_SUBST() variable (e.g., > LDMAXDATA).

Re: [Python-Dev] Stop automerging

On Wed, Sep 12, 2018, at 01:33, Serhiy Storchaka wrote: > 12.09.18 01:34, Miss Islington (bot) пише: > > https://github.com/python/cpython/commit/d13e59c1b512069d90efe7ee9b613d3913e79c56 > > commit: d13e59c1b512069d90efe7ee9b613d3913e79c56 > > branch: master > >

Re: [Python-Dev] Python 2.7 EOL date

_ > 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/benjamin%40python.org ___ Python-Dev mail

Re: [Python-Dev] A Subtle Bug in Class Initializations

This would be a good thing to fix. The only hard part is dealing with thirdparty extensions. Note we also have been working around this problem by putting PyType_Ready calls in various generic code paths of the interpreter when an uninitialized type passes through. On Mon, Aug 6, 2018, at 11:0

Re: [Python-Dev] Unicode 11.0.0 released

On Tue, Jun 5, 2018, at 12:17, MRAB wrote: > Unicode 11.0.0 has been released. Will Python 3.7 be updated to it, or > is it too late? https://github.com/python/cpython/pull/7439 will update 3.8. Generally, we've considered updating the Unicode database to be a feature and not backported upda

Re: [Python-Dev] Python startup time

On Wed, May 2, 2018, at 09:42, Gregory Szorc wrote: > The direction Mercurial is going in is that `hg` will likely become a Rust > binary (instead of a #!python script) that will use an embedded Python > interpreter. So we will have low-level control over the interpreter via the > C API. I'd also

Re: [Python-Dev] [RELEASE] Python 2.7.15

API for Python" was my motivation for the PEP 546, but > it seems like he is busy and the TLS PEP doesn't move anymore :-( > https://www.python.org/dev/peps/pep-0543/ > > Victor > > 2018-05-01 6:09 GMT+02:00 Benjamin Peterson : > > Greetings, > > I'

[Python-Dev] [RELEASE] Python 2.7.15

macOS installers now ship with a builtin copy of OpenSSL. Additionally, there is a new additional installer variant for macOS 10.9+ that includes a built-in version of Tcl/Tk 8.6. See the installer README for more information. Happy May, Benjamin 2.7 release ma

[Python-Dev] [RELEASE] Python 2.7.15 release candidate 1

ship with a built-in copy of OpenSSL. Additionally, there is a new additional installer variant for macOS 10.9+ that includes a built-in version of Tcl/Tk 8.6. See the installer README for more information. Thank you, Benjamin (on behalf of 2.7's release team and co

[Python-Dev] 2.7.15 release schedule

Hi all, It's that time yet again: I'm planning to release 2.7.15 release candidate 1 on April 14 and a final release two weeks later on April 28. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubs

Re: [Python-Dev] Python 2.7 -- bugfix or security before EOL?

pecial case. > > > > Will there be a period where Py2.7 is in security-only status before > >> hitting EOL? > >> > > > > https://www.python.org/dev/peps/pep-0373 gives the public status. When > > Benjamin Peterson want to add something, he will. > > >

Re: [Python-Dev] How is the GitHub workflow working for people?

On Wed, Feb 21, 2018, at 13:22, Guido van Rossum wrote: > On Wed, Feb 21, 2018 at 9:53 AM, Brett Cannon wrote: > > > > > > > On Wed, 21 Feb 2018 at 09:30 Yury Selivanov > > wrote: > > > >> FWIW I'm extremely happy with the current workflow. The recent > >> improvements to @miss-islington (kudo

Re: [Python-Dev] "threading.Lock().locked()" is not documented

On Sat, Feb 3, 2018, at 11:25, Gregory P. Smith wrote: > On Wed, Jan 31, 2018 at 4:46 PM Jesus Cea wrote: > > > https://docs.python.org/3.6/library/threading.html doesn't document > > "threading.Lock().locked()", and it is something quite useful. > > > > In fact, it is used in "threading.py" it

Re: [Python-Dev] Python 2.7, long double vs allocator alignment, GCC 8 on x86-64

s I can see, it has not been fixed on > >> the 2.7 branch. > >> > >> (Store merging is a relatively new GCC feature. Among other things, > >> this means that on x86-64, for sufficiently aligned pointers, vector > >> instructions are used to update multiple

Re: [Python-Dev] Drop support for old unsupported FreeBSD and Linux kernels?

Victor > ___ > 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/benjamin%40python.org ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Whatever happened to 'nonlocal x = y'?

-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/benjamin%40python.org > Email had 1 attachment: > + signature.asc > 1k (application/pgp-signature) ___ Python-Dev mailing list Python-Dev@python.org https://mail.

Re: [Python-Dev] Whatever happened to 'nonlocal x = y'?

On Fri, Jan 5, 2018, at 01:57, Nathaniel Smith wrote: > Was this just an oversight, or did it get rejected at some point and > no-one remembered to update that PEP? There was an implementation https://bugs.python.org/issue4199. But several years ago, we again reached the conclusion that the fe

Re: [Python-Dev] Heap allocate type structs in native extension modules?

On Thu, Dec 28, 2017, at 03:29, Erik Bray wrote: > On Tue, Dec 26, 2017 at 3:00 PM, Benjamin Peterson > wrote: > > I imagine Cython already takes care of this? > > This appears to have a distinct purpose, albeit not unrelated to > Cython. The OP's program would g

Re: [Python-Dev] Heap allocate type structs in native extension modules?

ter to use dynamically allocated type structs in native > modules?> > -- > > cheers, > Hugh Fisher > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/pytho

Re: [Python-Dev] Broken svn lookup?

I turned viewvc off a few months ago because subversion is highly deprecated at this point. In fact, now that Windows build dependencies have moved off, I’m probably going to shut it off for good soon. On Mon, Dec 18, 2017, at 06:55, Victor Stinner wrote: > Hi, > > I was looking at old issues. In

Re: [Python-Dev] Intention to accept PEP 552 soon (deterministic pyc files)

On Wed, Oct 4, 2017, at 07:14, Barry Warsaw wrote: > On Oct 3, 2017, at 13:29, Benjamin Peterson wrote: > > > I'm not sure turning the implementation details of our internal formats > > into APIs is the way to go. > > I still think an API in the stdlib would b

Re: [Python-Dev] Intention to accept PEP 552 soon (deterministic pyc files)

On Tue, Oct 3, 2017, at 08:03, Barry Warsaw wrote: > Guido van Rossum wrote: > > There have been no further comments. PEP 552 is now accepted. > > > > Congrats, Benjamin! Go ahead and send your implementation for review.Oops. > > Let me try that again. > > Whi

Re: [Python-Dev] Intention to accept PEP 552 soon (deterministic pyc files)

zing them under importlib for a while and just never gotten > around > to sitting down and coming up with a better design that warranted putting > the time into it. :) > > On Fri, 29 Sep 2017 at 09:17 Benjamin Peterson > wrote: > > > Thanks, Guido and everyone who submit

Re: [Python-Dev] Intention to accept PEP 552 soon (deterministic pyc files)

Thanks, Guido and everyone who submitted feedback! I guess I know what I'll be doing this weekend. On Fri, Sep 29, 2017, at 08:18, Guido van Rossum wrote: > Let me try that again. > > There have been no further comments. PEP 552 is now accepted. > > Congrats, Benjamin! Go

[Python-Dev] [RELEASE] Python 2.7.14

ython-2714/ Bugs may be reported at https://bugs.python.org/ Warmly, Benjamin 2.7 release manager (on behalf of all of 2.7's contributors) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev U

Re: [Python-Dev] PEP 556: Threaded garbage collection

On Fri, Sep 8, 2017, at 12:13, Antoine Pitrou wrote: > On Fri, 08 Sep 2017 12:04:10 -0700 > Benjamin Peterson wrote: > > I like it overall. > > > > - I was wondering what happens during interpreter shutdown. I see you > > have that listed as a open issue. How

Re: [Python-Dev] PEP 556: Threaded garbage collection

On Fri, Sep 8, 2017, at 12:24, Larry Hastings wrote: > > > On 09/08/2017 12:04 PM, Benjamin Peterson wrote: > > - Why not run all (Python) finalizers on the thread and not just ones > > from cycles? > > Two reasons: > > 1. Because some code relies on the fin

Re: [Python-Dev] PEP 556: Threaded garbage collection

No nightmares were harmed while writing this PEP. > > ___ > 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/benjamin%40python

Re: [Python-Dev] PEP 552: deterministic pycs

goals was for the existing timestamp-based pyc > >> format to remain completely unchanged, so we need some kind of marker > >> in the magic number to indicate whether the file is using the new > >> format or nor. > > > > I don't think that's a useful go

Re: [Python-Dev] PEP 552: deterministic pycs

On Thu, Sep 7, 2017, at 16:58, Gregory P. Smith wrote: > +1 on this PEP. Thanks! > Questions: > > Input from OS package distributors would be interesting. Would they use > this? Which way would it impact their startup time (loading the .py file > vs just statting it. does that even matter?

Re: [Python-Dev] PEP 552: deterministic pycs

On Thu, Sep 7, 2017, at 14:43, Guido van Rossum wrote: > On Thu, Sep 7, 2017 at 2:40 PM, Benjamin Peterson > wrote: > > > > > > > On Thu, Sep 7, 2017, at 14:19, Guido van Rossum wrote: > > > Nice one. > > > > > > It would be nice t

Re: [Python-Dev] PEP 552: deterministic pycs

On Thu, Sep 7, 2017, at 14:54, Antoine Pitrou wrote: > On Thu, 07 Sep 2017 14:32:19 -0700 > Benjamin Peterson wrote: > > > > > > Not sure how common that situation is (certainly the source tree wasn't > > > read-only when you checked it ou

Re: [Python-Dev] PEP 552: deterministic pycs

On Thu, Sep 7, 2017, at 14:19, Guido van Rossum wrote: > Nice one. > > It would be nice to specify the various APIs needed as well. The compileall and py_compile ones? > > Why do you keep the mtime-based format as an option? (Maybe because it's > faster? Did you measure it?) I haven't actual

Re: [Python-Dev] PEP 552: deterministic pycs

On Thu, Sep 7, 2017, at 14:21, Antoine Pitrou wrote: > On Thu, 07 Sep 2017 14:08:58 -0700 > Benjamin Peterson wrote: > > On Thu, Sep 7, 2017, at 14:00, Antoine Pitrou wrote: > > > On Thu, 07 Sep 2017 13:39:21 -0700 > > > Benjamin Peterson wrote: > > >

Re: [Python-Dev] PEP 552: deterministic pycs

On Thu, Sep 7, 2017, at 14:19, Freddy Rietdijk wrote: > > The main objection to that model is that it requires modifying source > timestamps, which isn't possible for builds on read-only source trees. > > Why not set the source timestamps of the source trees to say 1 first? If the source-tree i

  1   2   3   4   5   6   7   8   9   10   >