[Python-Dev] Re: [SPAM] Re: Switching to Discourse

On 15/07/2022 16:09, Rob Boehne via Python-Dev wrote: 100% agree – dealing with 5 or more platforms for discussion groups is a nightmare, and I tend not to follow any of them as closely for that reason. I agree. I don't mind having to use Discourse if I want to take part in a discussion but 99

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

On 05/10/2021 07:59, Nick Coghlan wrote: On Tue, 28 Sep 2021, 6:55 am Brett Cannon, wrote: On Sun, Sep 26, 2021 at 3:51 AM Phil Thompson via Python-Dev < python-dev@python.org> wrote: However the stable ABI is still a second class citizen as it is still not possible (AFAIK) to spe

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

On 27/09/2021 21:53, Brett Cannon wrote: On Sun, Sep 26, 2021 at 3:51 AM Phil Thompson via Python-Dev < python-dev@python.org> wrote: On 26/09/2021 05:21, Steven D'Aprano wrote: [snip] > These are not rhetorical questions, I genuinely do not know. I *think* > that there

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

On 26/09/2021 05:21, Steven D'Aprano wrote: [snip] As for the C-API... Python is 30 years old. Has it ever had a stable C-API before now? Hasn't it *always* been the case that C packages have targetted a single version and need to be rebuilt from source on every release? No. These are not r

[Python-Dev] Re: Understanding "is not safe" in typeobject.c

On 02/02/2021 23:08, Greg Ewing wrote: On 3/02/21 4:52 am, Phil Thompson wrote: Thanks - that's fairly definitive, although I don't really understand why __new__ has this particular requirement. The job of tp_new is to initialise the C struct. To do this, it first has to init

[Python-Dev] Re: Understanding "is not safe" in typeobject.c

On 02/02/2021 14:18, Greg Ewing wrote: On 3/02/21 12:07 am, Phil Thompson wrote: On 01/02/2021 23:50, Greg Ewing wrote: At the C level, there is always a *single* inheritance hierarchy. Why? Because a C struct can only extend one other C struct. Yes - I misunderstood what you meant by

[Python-Dev] Re: Understanding "is not safe" in typeobject.c

ll object.__new__(). (If you want us to change the code, please file a bpo bug report. I know that's no fun, but it's the way to get the right people involved.) Happy to do that but I first wanted to check if I was doing something "silly" - I'm still not sure.

[Python-Dev] Re: Understanding "is not safe" in typeobject.c

On 01/02/2021 23:50, Greg Ewing wrote: On 2/02/21 12:13 am, Phil Thompson via Python-Dev wrote: TypeError: object.__new__(B) is not safe, use B.__new__() It's not safe because object.__new__ doesn't know about any C-level initialisation that A or B need. But A.__new__ is call

[Python-Dev] Understanding "is not safe" in typeobject.c

Hi, I'm trying to understand the purpose of the check in tp_new_wrapper() of typeobject.c that results in the "is not safe" exception. I have the following class hierarchy... B -> A -> object ...where B and A are implemented in C. Class A has an implementation of tp_new which does a few con

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

On 28/12/2020 11:27, Inada Naoki wrote: On Mon, Dec 28, 2020 at 7:22 PM Phil Thompson wrote: > So I'm +1 to make Unicode simple by removing PyUnicode_READY(), and -1 > to make Unicode complicated by adding customizable callback for lazy > population. > > Anyway, I a

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

On 28/12/2020 02:07, Inada Naoki wrote: On Sun, Dec 27, 2020 at 8:20 PM Ronald Oussoren via Python-Dev wrote: On 26 Dec 2020, at 18:43, Guido van Rossum wrote: On Sat, Dec 26, 2020 at 3:54 AM Phil Thompson via Python-Dev wrote: That wouldn’t be a solution for code using the PyUnicode_

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

On 26/12/2020 10:52, Ronald Oussoren via Python-Dev wrote: On 25 Dec 2020, at 23:03, Nelson, Karl E. via Python-Dev wrote: I was directed to post this request to the general Python development community so hopefully this is on topic. One of the weaknesses of the PyUnicode implementation is

[Python-Dev] Re: PEP: Modify the C API to hide implementation details

On 11/04/2020 13:08, Ivan Pozdeev via Python-Dev wrote: On 10.04.2020 20:20, Victor Stinner wrote: Stable ABI -- The idea is to build a C extension only once: the built binary will be usable on multiple Python runtimes and different versions of the same runtime (stable ABI). The idea

[Python-Dev] Re: v3.8b1 Breaks PyQt on Windows (Issue 36085/os.add_dll_directory())

ing the beta. Please file this as an issue at bugs.python.org. Doing so would be helpful for folks who can look into the issue. Thanks, Carol On 6/22/19 2:04 PM, Phil Thompson wrote: The implementation of issue 36085 breaks PyQt on Windows as it relies on PATH to find the Qt DLLs. The problem is

[Python-Dev] v3.8b1 Breaks PyQt on Windows (Issue 36085/os.add_dll_directory())

The implementation of issue 36085 breaks PyQt on Windows as it relies on PATH to find the Qt DLLs. The problem is that PyQt is built using the stable ABI and a single wheel is supposed to support all versions of Python starting with v3.5. On the assumption (perhaps naive) that using the stable

Re: [Python-Dev] Experiences with Creating PEP 484 Stub Files

On 10 Feb 2016, at 5:52 pm, Guido van Rossum wrote: > > On Wed, Feb 10, 2016 at 1:11 AM, Phil Thompson > wrote: >> I understand now. The documentation, as it stands, is correct and consistent >> but (to me) the meaning of Optional is completely counter-intuitive. What &g

Re: [Python-Dev] Experiences with Creating PEP 484 Stub Files

> On 9 Feb 2016, at 11:48 pm, Guido van Rossum wrote: > > [Phil] I found the documentation confusing regarding Optional. Intuitively it seems to be the way to specify arguments with default values. However it is explained in terms of (for example) Union[str, None] and I (intuiti

Re: [Python-Dev] Experiences with Creating PEP 484 Stub Files

On 9 Feb 2016, at 8:54 pm, Guido van Rossum wrote: > > [Just adding to Andrew's response] > > On Tue, Feb 9, 2016 at 9:58 AM, Andrew Barnert via Python-Dev > wrote: >> On Feb 9, 2016, at 03:44, Phil Thompson wrote: >>> >>> There are a number of

[Python-Dev] Experiences with Creating PEP 484 Stub Files

I've been adding support to the SIP wrapper generator for automatically generating PEP 484 compatible stub files so that future versions of PyQt can be shipped with them. By way of feedback I thought I'd share my experience, confusions and suggestions. There are a number of things I'd like to e

Re: [Python-Dev] zipimport.c broken with implicit namespace packages

On 3 Jan 2016, at 5:33 pm, Brett Cannon wrote: > > > > On Sun, 3 Jan 2016 at 02:55 Phil Thompson wrote: > On 3 Jan 2016, at 3:41 am, Guido van Rossum wrote: > > > > On Sat, Jan 2, 2016 at 3:26 PM, wrote: > > > > -- > > >>>>

Re: [Python-Dev] zipimport.c broken with implicit namespace packages

On 3 Jan 2016, at 3:41 am, Guido van Rossum wrote: > > On Sat, Jan 2, 2016 at 3:26 PM, wrote: > > -- > > "Brett" == Brett Cannon writes: > > > I opened > > https://bugs.python.org/issue25711 to specifically try to > > fix this issue once and for all and along the way modernize

Re: [Python-Dev] Python 3.5.1 plans

On 1 Nov 2015, at 10:30 a.m., Chris Angelico wrote: > > PEP 478 [1] doesn't currently have any info on a planned 3.5.1 release > (and actually, it has 3.5.0 Final listed as a future release). About > when is it likely to happen? The one thing I'm hanging out for is an > installer patch on Windows

Re: [Python-Dev] Exposing the Android platform existence to Python modules

On 03/08/2014 4:58 pm, Guido van Rossum wrote: But *are* we going to support Android officially? What's the point? Do you have a plan for getting Python apps to first-class status in the App Store (um, Google Play)? I do... http://pyqt.sourceforge.net/Docs/pyqtdeploy/introduction.html Phil

Re: [Python-Dev] Exposing the Android platform existence to Python modules

On 02/08/2014 7:36 pm, Guido van Rossum wrote: On Sat, Aug 2, 2014 at 12:53 AM, Phil Thompson wrote: To me the issue is whether, for a particular value of sys.platform, the programmer can expect a particular Python stdlib API. If so then Android needs a different value for sys.platform

Re: [Python-Dev] Exposing the Android platform existence to Python modules

On 02/08/2014 4:34 am, Guido van Rossum wrote: Or SL4A? (https://github.com/damonkohler/sl4a) On Fri, Aug 1, 2014 at 8:06 PM, Steven D'Aprano wrote: On Sat, Aug 02, 2014 at 05:53:45AM +0400, Akira Li wrote: > Python uses os.name, sys.platform, and various functions from `platform` > modul

Re: [Python-Dev] Does Zip Importer have to be Special?

On 24/07/2014 7:26 pm, Brett Cannon wrote: On Thu Jul 24 2014 at 2:12:20 PM, Phil Thompson wrote: On 24/07/2014 6:48 pm, Brett Cannon wrote: > IOW allowing for easy patching of Python is probably the best option I > can > think of. Would tweaking importlib._bootstrap._install()

Re: [Python-Dev] Does Zip Importer have to be Special?

On 24/07/2014 9:42 pm, Nick Coghlan wrote: On 25 Jul 2014 03:51, "Brett Cannon" wrote: The problem with all of this is you are essentially asking for a hook to let you have code have access to the interpreter state before it is fully initialized. Zipimport and the various bits of code that ge

Re: [Python-Dev] Does Zip Importer have to be Special?

On 24/07/2014 6:48 pm, Brett Cannon wrote: On Thu Jul 24 2014 at 1:07:12 PM, Phil Thompson wrote: I have an importer for use in applications that embed an interpreter that does a similar job to the Zip importer (except that the storage is a C data structure rather than a .zip file). Just

[Python-Dev] Does Zip Importer have to be Special?

I have an importer for use in applications that embed an interpreter that does a similar job to the Zip importer (except that the storage is a C data structure rather than a .zip file). Just like the Zip importer I need to import my importer and add it to sys.path_hooks. However the earliest op

Re: [Python-Dev] Python 2.7 patch levels turning two digit

On 21/06/2014 10:37 pm, M.-A. Lemburg wrote: That said, and I also included this in my answers to the questions that Nick removed in his reply, I don't think that a lot of code would be affected by this. I do believe that we can use this potential breakage as a chance for improvement. See the las

Re: [Python-Dev] _PyUnicode_CheckConsistency() too strict?

On 03-02-2014 5:52 pm, Guido van Rossum wrote: Can we provide a convenience API (or even a few lines of code one could copy+paste) that determines if a particular 8-bit string should  have max-char equal to 127 or 255? I can easily imagine a number of use cases where this would come in handy (e.g

Re: [Python-Dev] _PyUnicode_CheckConsistency() too strict?

On 03-02-2014 4:38 pm, Paul Moore wrote: On 3 February 2014 16:10, Phil Thompson wrote: That doesn't answer my original question, that just works around the use case I presented. To restate... Why is a Latin-1 string considered inconsistent just because it doesn't happen to c

Re: [Python-Dev] _PyUnicode_CheckConsistency() too strict?

On 03-02-2014 4:04 pm, Victor Stinner wrote: 2014-02-03 Phil Thompson : Are you saying that code will fail if a particular Latin-1 string just happens not to contains any character greater than 127? PyUnicode_FromKindAndData(PyUnicode_1BYTE_KIND, latin1_str, length) accepts latin1 and ASCII

Re: [Python-Dev] _PyUnicode_CheckConsistency() too strict?

On 03-02-2014 3:35 pm, Victor Stinner wrote: 2014-02-03 Phil Thompson : For example, a string created with a maxchar of 255 (ie. a Latin-1 string) must contain at least one character in the range 128-255 otherwise you get an assertion failure. Yes, it's the specification of the PEP 393

[Python-Dev] _PyUnicode_CheckConsistency() too strict?

_PyUnicode_CheckConsistency() checks that the contents of the string matches the _KIND of the string. However it does this in a very strict manner, ie. that the contents *exactly* match the _KIND rather than just detecting an inconsistency between the contents and the _KIND. For example, a str

Re: [Python-Dev] Binary Compatibility Issue with Python v2.6.5 and v3.1.2

On Tue, 20 Apr 2010 22:24:44 +0200, "Martin v. Löwis" wrote: > Phil Thompson wrote: >> When I build my C++ extension on Windows (specifically PyQt with MinGW) >> against Python v2.6.5 it fails to run under v2.6.4. The same problem >> exists >> when building ag

Re: [Python-Dev] Binary Compatibility Issue with Python v2.6.5 and v3.1.2

On Tue, 20 Apr 2010 21:50:51 +0900, David Cournapeau wrote: > On Tue, Apr 20, 2010 at 9:19 PM, Phil Thompson > wrote: >> When I build my C++ extension on Windows (specifically PyQt with MinGW) >> against Python v2.6.5 it fails to run under v2.6.4. The same problem >>

[Python-Dev] Binary Compatibility Issue with Python v2.6.5 and v3.1.2

When I build my C++ extension on Windows (specifically PyQt with MinGW) against Python v2.6.5 it fails to run under v2.6.4. The same problem exists when building against v3.1.2 and running under v3.1.1. The error message is... ImportError: DLL load failed: The specified procedure could not be fou

Re: [Python-Dev] Python 3.0.1

On Fri, 30 Jan 2009 07:03:03 -0500, Steve Holden wrote: > Antoine Pitrou wrote: >> Raymond Hettinger rcn.com> writes: >>> * If you're thinking that shelves have very few users and that >>> 3.0.0 has had few adopters, doesn't that mitigate the effects >>> of making a better format available in

Re: [Python-Dev] Reminder: last alphas next Wednesday 07-May-2008

On Friday 02 May 2008, Nick Coghlan wrote: > Jeroen Ruigrok van der Werven wrote: > > -On [20080502 10:50], Steve Holden ([EMAIL PROTECTED]) wrote: > >> Groan. Then everyone else realizes what a "great idea" this is, and we > >> see ~/Perl/, ~/Ruby/, ~/C# (that'll screw the Microsoft users, a > >>

Re: [Python-Dev] C-API status of Python 3?

On Sunday 02 March 2008, Alex Martelli wrote: > On Sun, Mar 2, 2008 at 10:39 AM, Gregory P. Smith <[EMAIL PROTECTED]> wrote: > > On 3/2/08, Christian Heimes <[EMAIL PROTECTED]> wrote: > > > Alex Martelli wrote: > > > > Yep, but please do keep the PyUnicode for str and PyString for bytes > > > > (as

Re: [Python-Dev] Encouraging developers

On Tuesday 06 March 2007 1:42 pm, Jeremy Hylton wrote: > On 3/6/07, Georg Brandl <[EMAIL PROTECTED]> wrote: > > Raymond Hettinger schrieb: > > > [Phil Thompson] > > > > > >> I think a lot of people care, but many can't > > >&g

Re: [Python-Dev] Encouraging developers

On Tuesday 06 March 2007 6:15 am, Raymond Hettinger wrote: > [Phil Thompson] > > > I think a lot of people care, but many can't > > do anything about because the barrier to entry is too great. > > Do you mean commit priviledges? ISTM, those tend to be > handed

Re: [Python-Dev] Encouraging developers

On Tuesday 06 March 2007 6:00 am, Martin v. Löwis wrote: > Phil Thompson schrieb: > >>> Any ideas for fixing this problem? > >> > >> A better patch-tracker, better procedures for reviewing patches > >> surounding this new tracker, one or more proper dvcs

Re: [Python-Dev] Encouraging developers

On Tuesday 06 March 2007 5:49 am, Martin v. Löwis wrote: > Phil Thompson schrieb: > > I'm not sure what your point is. My point is that, if you want to > > encourage people to become core developers, they have to have a method of > > graduating through the ranks - lear

Re: [Python-Dev] Encouraging developers

On Tuesday 06 March 2007 5:42 am, Martin v. Löwis wrote: > Phil Thompson schrieb: > > 1. Don't suggest to people that, in order to get their patch reviewed, > > they should review other patches. The level of knowledge required to put > > together a patch is much less tha

Re: [Python-Dev] Encouraging developers

On Monday 05 March 2007 9:38 pm, Thomas Wouters wrote: > On 3/5/07, A.M. Kuchling <[EMAIL PROTECTED]> wrote: > > >From > > > 4. The patch mafia. I like everyone on python-dev that I meet, > > but somehow it is ann

Re: [Python-Dev] Encouraging developers

On Monday 05 March 2007 8:09 pm, Oleg Broytmann wrote: > On Mon, Mar 05, 2007 at 07:30:20PM +0000, Phil Thompson wrote: > > 1. Don't suggest to people that, in order to get their patch reviewed, > > they should review other patches. The level of knowledge required to put >

Re: [Python-Dev] Encouraging developers

On Monday 05 March 2007 6:46 pm, A.M. Kuchling wrote: > >From : > > 4. The patch mafia. I like everyone on python-dev that I meet, > but somehow it is annoyingly difficult to get a patch into > Python. Like thread

Re: [Python-Dev] The "i" string-prefix: I18n'ed strings

On Saturday 08 April 2006 1:05 am, Barry Warsaw wrote: > On Sat, 2006-04-08 at 00:45 +0200, "Martin v. Löwis" wrote: > > *Never* try to do i18n that way. Don't combine fragments through > > concatenation. Instead, always use placeholders. > > Martin is of course absolutely right! > > > If you have

Re: [Python-Dev] Switch to MS VC++ 2005 ?!

On Monday 27 February 2006 5:51 pm, Alex Martelli wrote: > On 2/27/06, M.-A. Lemburg <[EMAIL PROTECTED]> wrote: > > Microsoft has recently released their express version of the Visual C++. > > Given that this version is free for everyone, wouldn't it make sense > > to ship Python 2.5 compiled with

Re: [Python-Dev] Inconsistent Use of Buffer Interface in stringobject.c

On Monday 24 October 2005 7:39 pm, Guido van Rossum wrote: > On 10/24/05, M.-A. Lemburg <[EMAIL PROTECTED]> wrote: > > Guido van Rossum wrote: > > > A concern I'd have with fixing this is that Unicode objects also > > > support the buffer API. In any situation where either str or unicode > > > is a

Re: [Python-Dev] Inconsistent Use of Buffer Interface in stringobject.c

On Monday 24 October 2005 7:39 pm, Guido van Rossum wrote: > On 10/24/05, M.-A. Lemburg <[EMAIL PROTECTED]> wrote: > > Guido van Rossum wrote: > > > A concern I'd have with fixing this is that Unicode objects also > > > support the buffer API. In any situation where either str or unicode > > > is a

[Python-Dev] Inconsistent Use of Buffer Interface in stringobject.c

I'm implementing a string-like object in an extension module and trying to make it as interoperable with the standard string object as possible. To do this I'm implementing the relevant slots and the buffer interface. For most things this is fine, but there are a small number of methods in stri

Re: [Python-Dev] super_getattro() Behaviour

4. Am I missing a more correct/obvious technique? (There is no need to support classic classes.) >>> >>> Hum, I can't think of one, I'm afraid. >>> >>> There has been some vague talk of having a tp_lookup slot in >>> typeobjects, so >>> >>> PyDict_GetItem(t->tp_dict, x); >>> >>> would bec

Re: [Python-Dev] super_getattro() Behaviour

> "Phil Thompson" <[EMAIL PROTECTED]> writes: > >> In PyQt, wrapped types implement lazy access to the type dictionary >> through tp_getattro. If the normal attribute lookup fails, then private >> tables are searched and the attribute (if found) is created o

[Python-Dev] super_getattro() Behaviour

In PyQt, wrapped types implement lazy access to the type dictionary through tp_getattro. If the normal attribute lookup fails, then private tables are searched and the attribute (if found) is created on the fly and returned. It is also put into the type dictionary so that it is found next time thro