On Fri, Dec 06, 2019 at 11:10:49AM +, Paul Moore wrote:
[...]
> > They might end up with a million dynamically created classes, each with
> > a single instance, when what they wanted was a single class with a
> > million instances.
>
> But isn't that the point here? A limit would catch this an
On 12/06/2019 03:19 PM, Gregory P. Smith wrote:
I'd prefer it if we stayed on topic here...
I find discussion of other computing limits, and how and why they failed (and
the hassles of working around them), very relevant.
--
~Ethan~
___
Python-Dev
Steve Dower wrote:
> GitHub Actions *is* a CI service now, so my PR is actually using their
> machines for Windows/macOS/Ubuntu build and test.
Oh I see, that makes more sense. Thanks for the clarification.
Steve Dower wrote:
> It doesn't change the ease of enabling/disabling anything - that's st
I'd prefer it if we stayed on topic here...
On Fri, Dec 6, 2019 at 3:15 PM Chris Angelico wrote:
> On Sat, Dec 7, 2019 at 9:58 AM Greg Ewing
> wrote:
> >
> > On 7/12/19 2:54 am, Rhodri James wrote:
> >
> > > You've talked some about not making the 640k mistake
> >
> > I think it's a bit unfair
On Thu, 2019-12-05 at 16:38 +, Mark Shannon wrote:
> 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
On Sat, Dec 7, 2019 at 9:58 AM Greg Ewing wrote:
>
> On 7/12/19 2:54 am, Rhodri James wrote:
>
> > You've talked some about not making the 640k mistake
>
> I think it's a bit unfair to call it a "mistake". They had a 1MB
> address space limit to work with, and that was a reasonable place
> to put
On 7/12/19 2:54 am, Rhodri James wrote:
You've talked some about not making the 640k mistake
I think it's a bit unfair to call it a "mistake". They had a 1MB
address space limit to work with, and that was a reasonable place
to put the division between RAM and display/IO space. If anything
is t
Hey,
we also found the same issue last year,
the solution was to un-define use and re-define
https://code.qt.io/cgit/qt-creator/plugin-pythonextensions.git/tree/docs/plugin.md#n137
Here you have the code example of the workaround:
https://code.qt.io/cgit/qt-creator/plugin-pythonextensions.git/tr
Abdur-Rahmaan Janhangeer
http://www.pythonmembers.club | https://github.com/Abdur-rahmaanJ
Mauritius
On Wed, 4 Dec 2019, 06:52 Chris Angelico, wrote:
> Python made the choice to NOT limit
> its integers, and I haven't heard of any non-toy examples where an
> attacker causes you to evaluate 2**2*
Victor Stinner wrote:
> Isn't it already the current unwritten deprecation process?
Personally, I don't think we should rely on an unwritten process for
something as important and potentially breaking as a deprecation process.
Regardless of the outcome of this discussion, I think we should try to
In that case, would you mind to make Travis CI mandatory again?
Victor
Le ven. 6 déc. 2019 à 19:10, Brett Cannon a écrit :
>
> Victor Stinner wrote:
> > Hello,
> > Le mar. 26 nov. 2019 à 20:40, Brett Cannon br...@python.org a écrit :
> > > I have turned Travis off as a required check on the
> >
On 06Dec2019 1023, Kyle Stanley wrote:
Steve Dower wrote:
> As a related aside, I've been getting GitHub Actions support together
> (which I started at the sprints).
Would adding support for GitHub Actions make it easier/faster to
temporarily disable and re-enable specific CI services when th
ACTIVITY SUMMARY (2019-11-29 - 2019-12-06)
Python tracker at https://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open7180 (+10)
closed 43559 (+37)
total 50739 (+47)
Open issues wi
Victor Stinner wrote:
> Le ven. 6 déc. 2019 à 16:00, Guido van Rossum gu...@python.org a écrit :
> > Let's try to avoid having PEP discussions in the peps
> > tracker, period. That repo's tracker is only meant to handle markup and
> > grammar.
> > I recall that some PEPs have been discussed in len
Steve Dower wrote:
> As a related aside, I've been getting GitHub Actions support together
> (which I started at the sprints).
Would adding support for GitHub Actions make it easier/faster to
temporarily disable and re-enable specific CI services when they're having
external issues? IIUC, that see
Victor Stinner wrote:
> Hi,
> Le mer. 27 nov. 2019 à 19:40, Brett Cannon br...@python.org a écrit :
> > What do people think of the idea of requiring all
> > deprecations specifying a version that the feature will be removed in
> > (which under our
> > annual release cadence would be at least the
This mailing list is for discussing making _of_ Python, not _with_ it. You are
better to ask this over on python-list.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.or
Victor Stinner wrote:
> Hello,
> Le mar. 26 nov. 2019 à 20:40, Brett Cannon br...@python.org a écrit :
> > I have turned Travis off as a required check on the
> > 3.7, 3.8, and master branches until someone is able to get a fix in.
> > That makes me sad :-( Is there an issue at bugs.python.org to t
* The number of live coroutines in a running interpreter: Implicitly
limited by operating system limits until at least 3.11.
DOes the O.S. limit anything on a coroutine?
What for? As far as I know it is a minimal Python-only object, unless you
have each co-routine holding a reference
to a TCP sock
On 06Dec2019 0620, Victor Stinner wrote:
What's the status? Right now, I see Travis CI jobs passing on 3.7,
3.8 and master branches so I don't understand the problem. Maybe the
issue has been fixed and Travis CI can be made mandatory again?
They've been passing fine for me too, I'm not quite su
On 03/12/2019 17:15, 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?
>
> The PEP:
> https://github.com/markshannon/pe
Le ven. 6 déc. 2019 à 16:00, Guido van Rossum a écrit :
> Let's try to avoid having PEP discussions in the peps tracker, period. That
> repo's tracker is only meant to handle markup and grammar.
I recall that some PEPs have been discussed in length in GitHub PRs.
But I'm fine with keeping the di
Hi,
Le mer. 27 nov. 2019 à 19:40, Brett Cannon a écrit :
> What do people think of the idea of requiring all deprecations specifying a
> version that the feature will be removed in (which under our annual release
> cadence would be at least the third release from the start of the
> deprecation
Hii.I want to download Python 3.8.0 at my mobile.Please help me to download.
___
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/
Mes
On Sat, Dec 7, 2019 at 2:01 AM Guido van Rossum wrote:
>
> Let's try to avoid having PEP discussions in the peps tracker, period. That
> repo's tracker is only meant to handle markup and grammar.
>
> But if you want to prevent a PR from being merged, in general you should put
> [WIP] in the subj
Let's try to avoid having PEP discussions in the peps tracker, period. That
repo's tracker is only meant to handle markup and grammar.
But if you want to prevent a PR from being merged, in general you should
put [WIP] in the subject.
On Fri, Dec 6, 2019 at 06:21 Victor Stinner wrote:
> Hi,
>
>
Hello,
Le mar. 26 nov. 2019 à 20:40, Brett Cannon a écrit :
> I have turned Travis off as a required check on the 3.7, 3.8, and master
> branches until someone is able to get a fix in.
That makes me sad :-( Is there an issue at bugs.python.org to track
it? What's the status? Right now, I see Tr
Hi,
Le mer. 4 déc. 2019 à 00:58, Barry Warsaw a écrit :
>
> At the Steering Council’s November 12th meeting, we unanimously agreed to
> reject PEPs 606 and 608:
>
> * 606 - Python Compatibility Version
> (...)
> It was our opinion that neither PEP will effectively improve compatibility as
> pro
Apologies again for commenting in the wrong place.
On 05/12/2019 16:38, Mark Shannon wrote:
Memory access is usually a limiting factor in the performance of
modern CPUs. Better packing of data structures enhances locality and>
reduces memory bandwith, at a modest increase in ALU usage (for
shi
On Fri, Dec 6, 2019 at 12:14 PM Paul Moore wrote:
> On Fri, 6 Dec 2019 at 09:33, Steven D'Aprano wrote:
> >
> > Although I am cautiously and tentatively in favour of setting limits
> > if the benefits Mark suggests are correct, I have thought of at least
> > one case where a million classes may
On Thu, Dec 5, 2019 at 5:38 AM Mark Shannon wrote:
> From my limited googling, linux has a hard limit of about 600k file
> descriptors across all processes. So, 1M is well past any reasonable
> per-process limit. My impression is that the limits are lower on
> Windows, is that right?
Linux does
On Fri, 6 Dec 2019 at 09:33, Steven D'Aprano wrote:
>
> Although I am cautiously and tentatively in favour of setting limits
> if the benefits Mark suggests are correct, I have thought of at least
> one case where a million classes may not be enough.
>
> I've seen people write code like this:
>
>
Although I am cautiously and tentatively in favour of setting limits
if the benefits Mark suggests are correct, I have thought of at least
one case where a million classes may not be enough.
I've seen people write code like this:
for attributes in list_of_attributes:
obj = namedtupl
33 matches
Mail list logo
