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
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
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
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:
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
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
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
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
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
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
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
* 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
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
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:
>
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
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
>
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/
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
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
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
>
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
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 =
33 matches
Mail list logo
