On Wed, Nov 8, 2017 at 5:49 PM, Nick Coghlan wrote:
> On 8 November 2017 at 16:24, Guido van Rossum wrote:
> > I also don't like the idea that there's nothing you can do with a thunk
> > besides calling it -- you can't meaningfully introspect it (not without
> > building your own bytecode interp
On 9 November 2017 at 04:56, Barry Warsaw wrote:
> On Nov 8, 2017, at 08:47, Guido van Rossum wrote:
>>
>> You seem to have missed Nick's posts where he clearly accepts that a middle
>> ground is necessary. R D Murray is also still unconvinced. (And obviously I
>> myself am against reverting to
On Nov 8, 2017, at 16:10, Nick Coghlan wrote:
> The rationale for that change was so that end users of applications
> that merely happened to be written in Python wouldn't see deprecation
> warnings when Linux distros (or the end user) updated to a new Python
> version.
Instead they’d see breaka
> On Nov 8, 2017, at 8:30 AM, Serhiy Storchaka wrote:
>
> Macros Py_SETREF and Py_XSETREF were introduced in 3.6 and backported to all
> maintained versions ([1] and [2]). Despite their names they are private. I
> think that they are enough stable now and would be helpful in third-party
> cod
On 9 November 2017 at 02:28, Zachary Ware wrote:
> On Wed, Nov 8, 2017 at 8:39 AM, Erik Bray wrote:
>> a platform--in particular it's not clear when a buildbot is considered
>> "stable", or how to achieve that without getting necessary fixes
>> merged into the main branch in the first place.
>
>
> That'd be great for preserving kwargs' order after a pop() or a del?
To clarify, order is preserved after pop in Python 3.6 (and maybe 3.7).
There is discussion about breaking it to optimize for limited use cases,
but I don't think it's worth enough to discuss more until it demonstrates
real pe
On 8 November 2017 at 16:24, Guido van Rossum wrote:
> I also don't like the idea that there's nothing you can do with a thunk
> besides calling it -- you can't meaningfully introspect it (not without
> building your own bytecode interpreter anyway).
Wait, that wasn't what I was suggesting at all
On 9 November 2017 at 07:46, Antoine Pitrou wrote:
>
> Le 08/11/2017 à 22:43, Nick Coghlan a écrit :
>>
>> However, between them, the following two guidelines should provide
>> pretty good deprecation warning coverage for the world's Python code:
>>
>> 1. If it's in __main__, it will emit deprecat
2017-11-08 14:01 GMT-08:00 Jean-Patrick Francoia <
jeanpatrick.franc...@gmail.com>:
> This is my first post on this list, so please don't kill me if I ask it in
> the wrong place, or if the question is stupid.
>
>
> I asked this question on Stack Overflow already:
>
> https://stackoverflow.com/que
This is my first post on this list, so please don't kill me if I ask it
in the wrong place, or if the question is stupid.
I asked this question on Stack Overflow already:
https://stackoverflow.com/questions/47163048/python-annotations-difference-between-tuple-and
In very short, which form is
Le 08/11/2017 à 22:43, Nick Coghlan a écrit :
>
> However, between them, the following two guidelines should provide
> pretty good deprecation warning coverage for the world's Python code:
>
> 1. If it's in __main__, it will emit deprecation warnings at runtime
> 2. If it's not in __main__, it s
On 9 November 2017 at 07:09, Simon Cross wrote:
> On Wed, Nov 8, 2017 at 10:33 PM, Nick Coghlan wrote:
>> For interactive use, the principle ends up being "Code you write gives
>> deprecation warnings, code you import doesn't" (which is the main
>> aspect I care about, since it's the one that sem
On Wed, Nov 8, 2017 at 10:33 PM, Nick Coghlan wrote:
> For interactive use, the principle ends up being "Code you write gives
> deprecation warnings, code you import doesn't" (which is the main
> aspect I care about, since it's the one that semi-regularly trips me
> up when I forget that Deprecati
On Nov 8, 2017, at 12:02, Guido van Rossum wrote:
>
> I hadn't seen that, but it requires too much cooperation of library owners.
Actually, mostly just setuptools and as Paul points out, pip.
Cheers,
-Barry
signature.asc
Description: Message signed with OpenPGP
__
On 8 November 2017 at 19:21, Antoine Pitrou wrote:
> On Wed, 8 Nov 2017 11:35:13 +1000
> Nick Coghlan wrote:
>
>> On 8 November 2017 at 10:03, Guido van Rossum wrote:
>> > OK, so let's come up with a set of heuristics that does the right thing for
>> > those cases specifically. I'd say whenever
On 8 November 2017 at 18:56, Barry Warsaw wrote:
> On Nov 8, 2017, at 08:47, Guido van Rossum wrote:
>>
>> You seem to have missed Nick's posts where he clearly accepts that a middle
>> ground is necessary. R D Murray is also still unconvinced. (And obviously I
>> myself am against reverting to
I hadn't seen that, but it requires too much cooperation of library owners.
On Wed, Nov 8, 2017 at 10:56 AM, Barry Warsaw wrote:
> On Nov 8, 2017, at 08:47, Guido van Rossum wrote:
> >
> > You seem to have missed Nick's posts where he clearly accepts that a
> middle ground is necessary. R D Mur
On Nov 8, 2017, at 08:47, Guido van Rossum wrote:
>
> You seem to have missed Nick's posts where he clearly accepts that a middle
> ground is necessary. R D Murray is also still unconvinced. (And obviously I
> myself am against reverting to the behavior from 7 years ago.) If we can't
> agree o
Philipp,
You seem to have missed Nick's posts where he clearly accepts that a middle
ground is necessary. R D Murray is also still unconvinced. (And obviously I
myself am against reverting to the behavior from 7 years ago.) If we can't
agree on some middle ground, the status quo will be maintained
08.11.17 18:37, Victor Stinner пише:
I like these macros!
Technically, would it be possible to use an inline function instead of
a macro for Python 3.7?
No, unless there is a way to pass arguments by reference in C99.
Py_SETREF(x, y) is the safe equivalent of
x = y;
Py_DECREF(x, y);
I like these macros!
Technically, would it be possible to use an inline function instead of
a macro for Python 3.7?
Victor
2017-11-08 17:30 GMT+01:00 Serhiy Storchaka :
> Macros Py_SETREF and Py_XSETREF were introduced in 3.6 and backported to all
> maintained versions ([1] and [2]). Despite the
Macros Py_SETREF and Py_XSETREF were introduced in 3.6 and backported to
all maintained versions ([1] and [2]). Despite their names they are
private. I think that they are enough stable now and would be helpful in
third-party code. Are there any objections against adding them to the
stable C AP
On Wed, Nov 8, 2017 at 8:39 AM, Erik Bray wrote:
> a platform--in particular it's not clear when a buildbot is considered
> "stable", or how to achieve that without getting necessary fixes
> merged into the main branch in the first place.
I think in this context, "stable" just means "keeps a conn
On Wednesday, November 8, 2017, Guido van Rossum wrote:
> It seems there must be at least two threads for each topic worth
> discussing at all. Therefore I feel compelled to point to
> https://mail.python.org/pipermail/python-dev/2017-November/150381.html,
> where I state my own conclusion about
Hi folks,
As some people here know I've been working off and on for a while to
improve CPython's support of Cygwin. I'm motivated in part by a need
to have software working on Python 3.x on Cygwin for the foreseeable
future, preferably with minimal graft. (As an incidental side-effect
Python's t
On Wed, 8 Nov 2017 13:07:12 +1000
Nick Coghlan wrote:
> On 8 November 2017 at 07:19, Evpok Padding wrote:
> > On 7 November 2017 at 21:47, Chris Barker wrote:
> >> if dict order is preserved in cPython , people WILL count on it!
> >
> > I won't, and if people do and their code break, they'll
On Wed, 8 Nov 2017 11:35:13 +1000
Nick Coghlan wrote:
> On 8 November 2017 at 10:03, Guido van Rossum wrote:
> > OK, so let's come up with a set of heuristics that does the right thing for
> > those cases specifically. I'd say whenever you're executing code from a
> > zipfile or some such it's n
08.11.17 04:33, Nick Coghlan пише:
On 8 November 2017 at 11:44, Nick Coghlan wrote:
2. So far, I haven't actually come up with a perturbed iteration
implementation that doesn't segfault the interpreter. The dict
internals are nicely laid out to be iteration friendly, but they
really do assume t
28 matches
Mail list logo
