[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

[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 s

[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 wa

[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

[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 initialise

[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

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

(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. Phil On Mon, Feb 1, 2021 at 3:27

[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 calling object

[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

[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 am OK

[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

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

lease 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 that PyQt is b

[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 <gu...@python.org> wrote: > > On Wed, Feb 10, 2016 at 1:11 AM, Phil Thompson > <p...@riverbankcomputing.com> wrote: >> I understand now. The documentation, as it stands, is correct and consistent >> but (to me) the

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,

[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

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

On 9 Feb 2016, at 8:54 pm, Guido van Rossum <gu...@python.org> wrote: > > [Just adding to Andrew's response] > > On Tue, Feb 9, 2016 at 9:58 AM, Andrew Barnert via Python-Dev > <python-dev@python.org> wrote: >> On Feb 9, 2016, at 03:44, Phil Thompson &l

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

On 3 Jan 2016, at 5:33 pm, Brett Cannon <br...@python.org> wrote: > > > > On Sun, 3 Jan 2016 at 02:55 Phil Thompson <p...@riverbankcomputing.com> wrote: > On 3 Jan 2016, at 3:41 am, Guido van Rossum <gu...@python.org> wrote: > > > > On Sat, Jan

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 >

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 >

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 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 st...@pearwood.info wrote: On Sat, Aug 02, 2014 at 05:53:45AM +0400, Akira Li wrote: Python uses os.name, sys.platform, and various functions from

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 p...@riverbankcomputing.com 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

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 br...@python.org 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

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 p...@riverbankcomputing.com 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

[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

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 p...@riverbankcomputing.com 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

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

[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

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

On 03-02-2014 3:35 pm, Victor Stinner wrote: 2014-02-03 Phil Thompson p...@riverbankcomputing.com: 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

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

On 03-02-2014 4:04 pm, Victor Stinner wrote: 2014-02-03 Phil Thompson p...@riverbankcomputing.com: 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

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 p...@riverbankcomputing.com 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

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

[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

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 courn...@gmail.com wrote: On Tue, Apr 20, 2010 at 9:19 PM, Phil Thompson p...@riverbankcomputing.com 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

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 mar...@v.loewis.de 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 against v3.1.2 and running under

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 directory

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 macros/synonnyms

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 than that required to know if a patch

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 - learning (and being taught) as they go

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's for people to work off of. I'm not sure about

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 out readily to people who assert

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 +, 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 together a patch is much less

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 http://ivory.idyll.org/blog/mar-07/five-things-I-hate-about-python 4. The patch mafia. I like everyone on python-dev that I meet, but somehow it is annoyingly

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 many

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 accepted I'd

[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

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 accepted I'd

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 on the fly and returned. It is also put

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 become t-tp_lookup(x); (well, ish,

[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