On Fri, 30 Nov 2018 09:22:30 -0800
Steve Dower wrote:
>
> My proposed marketing pitch is: "rewrite your existing code to be
> forward-compatible today and faster in the future without more work, or
> be prepared to rewrite/update your source code for each CPython release
> to remain
Steve Dower wrote:
> My proposed marketing pitch is: "rewrite your existing code to be
> forward-compatible today and faster in the future without more work, or
> be prepared to rewrite/update your source code for each CPython release
> to remain compatible with the low level API". The
ACTIVITY SUMMARY (2018-11-23 - 2018-11-30)
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:
open6880 (+15)
closed 40234 (+47)
total 47114 (+62)
Open issues
On 2018-11-29, Armin Rigo wrote:
> ...Also, although I'm discussing it here, I think the whole approach
> would be better if done as a third-party extension for now, without
> requiring changes to CPython---just use the existing C API to
> implement the CPython version.
Hello Armin,
Thank you
On Fri, 30 Nov 2018 13:06:11 -0600
Neil Schemenauer wrote:
> On 2018-11-29, Armin Rigo wrote:
> > ...Also, although I'm discussing it here, I think the whole approach
> > would be better if done as a third-party extension for now, without
> > requiring changes to CPython---just use the existing C
On 11/29/2018 2:10 PM, Andrew Svetlov wrote:
Neither http.client nor http.server doesn't support compression
(gzip/compress/deflate) at all.
I doubt if we want to add this feature: for client better to use
requests or, well, aiohttp.
The same for servers: almost any production ready web server
On 29Nov2018 2206, Armin Rigo wrote:
On Thu, 29 Nov 2018 at 18:19, Steve Dower wrote:
quo. We continue to not be able to change CPython internals at all,
since that will break people using option B.
No? That will only break users if they only have an option-B
On 30Nov2018 1133, Antoine Pitrou wrote:
On Fri, 30 Nov 2018 13:06:11 -0600
Neil Schemenauer wrote:
On 2018-11-29, Armin Rigo wrote:
...Also, although I'm discussing it here, I think the whole approach
would be better if done as a third-party extension for now, without
requiring changes to
On Thu, 29 Nov 2018 10:46:23 -0800
Steve Dower wrote:
>
> I've previously volunteered to move certain modules to their own PyPI
> packages and bundle them (omitting package names to avoid upsetting
> people again), and I've done various analyses of which modules can be
> moved out. I've also
On Fri, 30 Nov 2018 13:00:37 -0800
Glenn Linderman wrote:
>
> So it would be nice if http.server and http.client could get some basic
> improvements to be complete, or if the docs could point to a replacement
> that is a complete server, but without a philosophy or framework
> (bloatware) to
Hi Steve,
On 30/11/2018, Steve Dower wrote:
> On 29Nov2018 2206, Armin Rigo wrote:
>> On Thu, 29 Nov 2018 at 18:19, Steve Dower wrote:
>>> quo. We continue to not be able to change CPython internals at all,
>>> since that will break people using option B.
>>
>> No? That will only break users
On 30Nov2018 1435, Antoine Pitrou wrote:
Sorry. I've been unfair and unduly antagonistic.
Apology is totally accepted and all is forgiven. Thank you.
Cheers,
Steve
___
Python-Dev mailing list
Python-Dev@python.org
On Fri, 30 Nov 2018 at 00:17, Steven D'Aprano wrote:
> Especially not *Paul's* problems, as I understand he personally is
> reasonably satisfied with the stdlib and doesn't use any of those
> third-party distros. (Paul, did I get that right?)
That's correct. And not just "reasonably satisfied" -
On Fri, Nov 30, 2018 at 2:12 AM Brett Cannon wrote:
>
>
> On Thu, 29 Nov 2018 at 14:12, Andrew Svetlov
> wrote:
>
>> Neither http.client nor http.server doesn't support compression
>> (gzip/compress/deflate) at all.
>> I doubt if we want to add this feature: for client better to use requests
>>
On Fri, 30 Nov 2018 11:14:47 +1100
Steven D'Aprano wrote:
>
> There are plenty of other languages that come with a tiny stdlib and
> leave everything else to third parties. Outside of those like
> Javascript, which has a privileged position due to it being the standard
> browser scripting
On Fri, Nov 30, 2018 at 01:45:17AM +, Oscar Benjamin wrote:
> They do include much more than we need so I'd agree that Anaconda is a
> nuclear reactor. The things I want from it are not though. Numpy is
> not a nuclear reactor: at it's core it's just providing a
> multidimensional array.
And
I just would want to say that I'm very happy to read the discussions
about the C API finally happening on python-dev :-) The discussion is
very interesting!
> C is really the lingua franca
Sorry, but why not writing the API directly in french?
Victor
17 matches
Mail list logo
