[Python-Dev] Re: Python 3.8 problem with PySide

No idea why gmail landed such an important email in the spam folder (i grit my teeth if pyside freezes @ <3.7) Abdur-Rahmaan Janhangeer http://www.pythonmembers.club | https://github.com/Abdur-rahmaanJ Mauritius > > ___ Python-Dev mailing list --

[Python-Dev] Python 3.8 problem with PySide

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!

[Python-Dev] PEP 611: The one million limit.

Hi Everyone, Thanks for all your feedback on my proposed PEP. I've editing the PEP in light of all your comments and it is now hopefully more precise and with better justification. https://github.com/python/peps/pull/1249 Cheers, Mark. ___

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

Hi, On 05/12/2019 12:54 pm, Tal Einat wrote: On Tue, Dec 3, 2019 at 6:23 PM Mark Shannon > wrote: Hi Everyone, I am proposing a new PEP, still in draft form, to impose a limit of one million on various aspects of Python programs, such as the lines of

[Python-Dev] Re: Deprecating the "u" string literal prefix

Le jeu. 5 déc. 2019 à 12:14, Thomas Wouters a écrit : > It should, but it doesn't always :) If you forget how your data is flawed, > the 'smarter' decision can easily be wrong, instead. I do think it's a good > idea to reject ideas that would break a certain number of PyPI packages, say, > but

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

> > Assuming a code base of 50M loc, *and* that all the code would be loaded > into a single application (I sincerely hope that isn't the case) *and* > that each class is only 100 lines, even then there would only be 500,000 > classes. > If a single application has 500k classes, I don't think that

[Python-Dev] Re: Deprecating the "u" string literal prefix

Please try to get an email client which is able to reply in a thread, rather than creating a new thread each time you send an email. You might want to try HyperKitty: https://mail.python.org/archives/list/python-dev@python.org/ Victor Le jeu. 5 déc. 2019 à 10:50, Anders Munch a écrit : > > >>

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

Hi Guido, On 04/12/2019 3:51 pm, Guido van Rossum wrote: I am overwhelmed by this thread (and a few other things in real life) but here are some thoughts. 1. It seems the PEP doesn't sufficiently show that there is a problem to be solved. There are claims of inefficiency but these aren't

[Python-Dev] Re: Macros instead of inline functions?

On 04/12/2019 18:22, Serhiy Storchaka wrote: In these files (symtable.c, compile.c, ast_opt.c, etc) there are sequences of calls for child nodes. Every call can return an error, so you need to check every call and return an error immediately after the call. With inline functions you would need

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

On 03/12/2019 5:22 pm, Steve Dower wrote: On 03Dec2019 0815, Mark Shannon wrote: Hi Everyone, I am proposing a new PEP, still in draft form, to impose a limit of one million on various aspects of Python programs, such as the lines of code per module. I assume you're aiming for

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

On Thu, Dec 5, 2019 at 6:23 PM Mark Shannon wrote: > > > On 05/12/2019 12:45 pm, Karthikeyan wrote: > > On Thu, Dec 5, 2019, 5:53 PM Mark Shannon > > wrote: > > > > > > > > On 04/12/2019 2:31 am, Gregory P. Smith wrote: > > > > > > > > > On Tue, Dec 3,

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

On Tue, Dec 3, 2019 at 6:23 PM Mark Shannon wrote: > Hi Everyone, > > I am proposing a new PEP, still in draft form, to impose a limit of one > million on various aspects of Python programs, such as the lines of code > per module. > > Any thoughts or feedback? > My two cents: I find the

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

On 05/12/2019 12:45 pm, Karthikeyan wrote: On Thu, Dec 5, 2019, 5:53 PM Mark Shannon > wrote: On 04/12/2019 2:31 am, Gregory P. Smith wrote: > > > On Tue, Dec 3, 2019 at 8:21 AM Mark Shannon mailto:m...@hotpy.org> >

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

On Thu, Dec 5, 2019, 5:53 PM Mark Shannon wrote: > > > On 04/12/2019 2:31 am, Gregory P. Smith wrote: > > > > > > On Tue, Dec 3, 2019 at 8:21 AM Mark Shannon > > wrote: > > > > Hi Everyone, > > > > I am proposing a new PEP, still in draft form, to impose a limit

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

On 04/12/2019 2:31 am, Gregory P. Smith wrote: On Tue, Dec 3, 2019 at 8:21 AM Mark Shannon > wrote: Hi Everyone, I am proposing a new PEP, still in draft form, to impose a limit of one million on various aspects of Python programs, such as the lines of

[Python-Dev] Re: Deprecating the "u" string literal prefix

On Wed, Dec 4, 2019 at 6:37 PM Victor Stinner wrote: > Le mer. 4 déc. 2019 à 14:49, Thomas Wouters a écrit : > >> (...) > >> It's very different if an incompatible change break 1% or 90% of > >> Python projects. > > > > Unfortunately there is a distinctive bias if you select popular > projects,

[Python-Dev] Re: Deprecating the "u" string literal prefix

>> I'm struggling to see what i-strings would do for i18n that str.format >> doesn't do better. Serhiy Storchaka [mailto:storch...@gmail.com] > You would not need to repeat yourself. > _('{name} costs ${price:.2f}').format(name=name, price=price) A small price to pay for having a

[Python-Dev] Re: Deprecating the "u" string literal prefix

Barry Warsaw [mailto:ba...@python.org] wrote: > str.format() really isn’t enough to do proper i18n; it’s actually a fairly > complex topic. Obviously. > I’m not convinced that PEP 501 would provide much benefit on the technical > side. My point exactly. > flufl.i18n -