I admit I spent the first half of the email scratching my head and trying
to figure out what NULL had to do with argument clinic specs. (Maybe it
would mean that if the argument is "not given" in some appropriate way then
we set the corresponding C variable to NULL?) Finding out you were talking
ab
On Fri, Oct 10, 2014 at 1:29 AM, Victor Stinner
wrote:
> Hi,
>
> Windows is not the primary target of Python developers, probably
> because most of them work on Linux. Official Python binaries are
> currently built by Microsoft Visual Studio. Even if Python developers
> get free licenses thanks fo
On 11 Oct 2014 14:42, "Antoine Pitrou" wrote:
>
> On Sat, 11 Oct 2014 00:30:51 + (UTC)
> Sturla Molden wrote:
> > Larry Hastings wrote:
> >
> > > CPython doesn't require OpenBLAS. Not that I am not receptive to the
> > > needs of the numeric community... but, on the other hand, who in the
>
I'm not at all an expert on Fortran ABIs, but I think there are two
distinct issues being conflated here.
The first is that there is no standard way to look at some Fortran source
code and figure out the corresponding C API. When trying to call a Fortran
routine from C, then different Fortran comp
On Mon, Oct 27, 2014 at 5:48 PM, Paul Moore wrote:
> On 26 October 2014 23:44, Paul Moore wrote:
>> On 26 October 2014 23:11, Ray Donnelly wrote:
>>> I don't know where this "ABI compatible" thing came into being;
>>
>> Simple. If a mingw-built CPython doesn't work with the same extensions
>> as
On 29 Oct 2014 14:47, "Antoine Pitrou" wrote:
>
> On Wed, 29 Oct 2014 10:31:50 -0400
> "R. David Murray" wrote:
>
> > On Wed, 29 Oct 2014 10:22:14 -0400, Tres Seaver
wrote:
> > > On 10/28/2014 11:59 PM, Stephen J. Turnbull wrote:
> > >
> > > > most developers on Windows do have access to Microso
On Wed, Oct 29, 2014 at 10:46 PM, Paul Moore wrote:
> On 29 October 2014 22:19, Ethan Furman wrote:
>>> Yeah, I wondered about that. I'll work up a patch for that. But the
>>> more I think about it, it really is trivial:
>>
>> I am reminded of an interview question I was once asked which was pref
On Tue, Nov 4, 2014 at 4:52 PM, Roberto Martínez
wrote:
> Hi folks,
>
> I am trying to replace dinamically the __call__ method of an object using
> setattr.
> Example:
>
> $ cat testcall.py
> class A:
> def __init__(self):
> setattr(self, '__call__', self.newcall)
>
> def __call__(
On 15 Nov 2014 10:10, "Paul Moore" wrote:
>
> > Incidentally, it would be really useful if python.org provided stable
> > url's that always redirected to the latest .msi installers, for
> > bootstrapping purposes. I'd prefer to not rely on chocolatey (or on
> > scraping the web site) for this.
>
>
Hi all,
There was some discussion on python-ideas last month about how to make
it easier/more reliable for a module to override attribute access.
This is useful for things like autoloading submodules (accessing
'foo.bar' triggers the import of 'bar'), or for deprecating module
attributes that aren
On Sat, Nov 29, 2014 at 4:21 AM, Guido van Rossum wrote:
> Are these really all our options? All of them sound like hacks, none of them
> sound like anything the language (or even the CPython implementation) should
> sanction. Have I missed the discussion where the use cases and constraints
> were
On Sat, Nov 29, 2014 at 11:32 AM, Antoine Pitrou wrote:
> On Sat, 29 Nov 2014 01:59:06 +
> Nathaniel Smith wrote:
>>
>> Option 1: Make it possible to change the type of a module object
>> in-place, so that we can write something like
>>
>>
dunno. So since we're *so close* to being able to just use the
subclassing machinery, it seemed cleaner to try and get that working
instead of reimplementing bits of it piecewise.
That said, __getattr__ + __dir__ would be enough for my immediate use cases.
-n
> On Sat, Nov 29, 2014 at 11
On Sun, Nov 30, 2014 at 7:27 PM, Ethan Furman wrote:
> On 11/30/2014 11:15 AM, Guido van Rossum wrote:
>> On Sun, Nov 30, 2014 at 6:15 AM, Brett Cannon wrote:
>>> On Sat, Nov 29, 2014, 21:55 Guido van Rossum wrote:
All the use cases seem to be about adding some kind of getattr hook
On Sun, Nov 30, 2014 at 10:14 PM, Mark Shannon wrote:
> Hi,
>
> This discussion has been going on for a while, but no one has questioned the
> basic premise. Does this needs any change to the language or interpreter?
>
> I believe it does not. I'm modified your original metamodule.py to not use
>
On Mon, Dec 1, 2014 at 12:59 AM, Nathaniel Smith wrote:
> On Sun, Nov 30, 2014 at 10:14 PM, Mark Shannon wrote:
>> Hi,
>>
>> This discussion has been going on for a while, but no one has questioned the
>> basic premise. Does this needs any change to the language or i
On Sun, Nov 30, 2014 at 8:54 PM, Guido van Rossum wrote:
> On Sun, Nov 30, 2014 at 11:29 AM, Nathaniel Smith wrote:
>>
>> On Sun, Nov 30, 2014 at 2:54 AM, Guido van Rossum
>> wrote:
>> > All the use cases seem to be about adding some kind of getattr hook to
is a pretty common way to get a handle to ModuleType -- in fact both
types.py and importlib use it.) So in my mind I sorta lumped it in
with my Option 2, "minor compatibility break". OTOH maybe anyone who
creates a module object without going through PyModule_New deserves
whatever they g
On Mon, Dec 1, 2014 at 4:06 AM, Guido van Rossum wrote:
> On Sun, Nov 30, 2014 at 5:42 PM, Nathaniel Smith wrote:
>>
>> On Mon, Dec 1, 2014 at 1:27 AM, Guido van Rossum wrote:
>> > Nathaniel, did you look at Brett's LazyLoader? It overcomes the subclass
>> &g
On Tue, Dec 2, 2014 at 9:19 AM, Antoine Pitrou wrote:
> On Mon, 1 Dec 2014 21:38:45 +
> Nathaniel Smith wrote:
>>
>> object_set_class is responsible for checking whether it's okay to take
>> an object of class "oldto" and convert it to an object of c
On 10 Dec 2014 17:16, "Ian Cordasco" wrote:
>
> On Wed, Dec 10, 2014 at 11:10 AM, Donald Stufft wrote:
> >
> > On Dec 10, 2014, at 11:59 AM, Bruno Cauet wrote:
> >
> > Hi all,
> > Last year a survey was conducted on python 2 and 3 usage.
> > Here is the 2014 edition, slightly updated (from 9 to
On 13 Feb 2015 02:09, "Victor Stinner" wrote:
>
> A alternative is to add a new _scandir.c module to host the new C
> code, and share some code with posixmodule.c: remove "static" keyword
> from required C functions (functions to convert Windows attributes to
> a os.stat_result object).
Hopefully
On Mar 8, 2015 9:13 PM, "Steven D'Aprano" wrote:
>
> There's no built-in way of calling __index__ that I know of (no
> equivalent to int(obj)),
There's operator.index(obj), at least.
> but slicing at the very least will call it,
> e.g. seq[a:] will call type(a).__index__.
-n
___
On Mar 23, 2015 8:15 AM, "Antoine Pitrou" wrote:
>
> On Mon, 23 Mar 2015 08:06:13 -0700
> Toshio Kuratomi wrote:
> > >
> > > I really think Donald has a good point when he suggests a specific
> > > virtualenv for system programs using Python.
> > >
> > The isolation is what we're seeking but I th
On Apr 3, 2015 5:50 PM, "Donald Stufft" wrote:
>
>
> > On Apr 3, 2015, at 6:38 PM, M.-A. Lemburg wrote:
> >
> > On 04.04.2015 00:14, Steve Dower wrote:
> >> The thing is, that's exactly the same goodness as Authenticode gives,
except everyone gets that for free and meanwhile you're the only one w
On Sat, Apr 4, 2015 at 6:07 PM, Steve Dower wrote:
> There's no problem, per se, but initially it was less trouble to use the
> trusted PSF certificate and native support than to add an extra step using a
> program I don't already use and trust, am restricted in use by my employer
> (because of th
On Apr 29, 2015 11:49 AM, "Yury Selivanov" wrote:
>
> Hi Ethan,
>
>
> On 2015-04-29 2:32 PM, Ethan Furman wrote:
>>
>> On 04/29, Yury Selivanov wrote:
>>>
>>> On 2015-04-29 1:25 PM, Ethan Furman wrote:
cannot also just work and be the same as the parenthesized
version.
>>>
>>> Becau
On Wed, Apr 29, 2015 at 1:14 PM, Skip Montanaro
wrote:
>
> On Wed, Apr 29, 2015 at 2:42 PM, Yury Selivanov
> wrote:
>>
>> Anyways, I'd be OK to start using a new term, if "coroutine" is
>> confusing.
>
>
> According to Wikipedia, term "coroutine" was first coined in 1958, so
> several generations
On Wed, Apr 29, 2015 at 3:46 PM, Greg Ewing wrote:
> Yury Selivanov wrote:
>>
>> I'm not sure
>> why Greg is pushing his Grammar idea so aggressively.
>
>
> Because I believe that any extra complexity in the grammar
> needs a very strong justification. It's complexity in the
> core language, like
On Wed, Apr 29, 2015 at 4:48 PM, Yury Selivanov wrote:
> Nathaniel,
>
> On 2015-04-29 7:35 PM, Nathaniel Smith wrote:
>>
>> What I do feel strongly about
>> is that whatever syntax we end up with, there should be*some*
>> accurate human-readable descripti
On Wed, Apr 29, 2015 at 5:05 PM, Yury Selivanov wrote:
> Nathaniel,
>
> On 2015-04-29 7:58 PM, Nathaniel Smith wrote:
>>
>> On Wed, Apr 29, 2015 at 4:48 PM, Yury Selivanov
>> wrote:
>>>
>>> Nathaniel,
>>>
>>> On 2015-04-29 7:35 PM,
On Apr 30, 2015 1:57 AM, "Greg Ewing" wrote:
>
> Nathaniel Smith wrote:
>>
>> Even if we put aside our trained intuitions about arithmetic, I think
>> it's correct to say that the way unary minus is parsed is: everything
>> to the right of it that h
On Apr 30, 2015 8:40 PM, "Guido van Rossum" wrote:
>
> On Thu, Apr 30, 2015 at 8:30 PM, Nathaniel Smith wrote:
>>
>> The actual effect of making "await" a different precedence is to resolve
the ambiguity in
>>
>> await x ** 2
>>
>>
On May 5, 2015 12:40 PM, "Jim J. Jewett" wrote:
>
>
> On Tue May 5 18:29:44 CEST 2015, Yury Selivanov posted an updated PEP492.
>
> Where are the following over-simplifications wrong?
>
[...snip...]
>
> [Note that the actual PEP uses iteration over the results of a new
> __await__ magic method, ra
On May 5, 2015 2:14 PM, "Guido van Rossum" wrote:
>
> In the PEP 492 world, these concepts map as follows:
>
> - Future translates to "something with an __await__ method" (and asyncio
Futures are trivially made compliant by defining Future.__await__ as an
alias for Future.__iter__);
>
> - "asyncio
Hi all,
While attempting to clean up some of the more squamous aspects of
numpy's operator dispatch code [1][2], I've encountered a situation
where the semantics we want and are using are possible according to
CPython-the-interpreter, but AFAICT ought not to be possible according
to Python-the-lan
ntially will save me a lot of time.
>>
>> So, everybody please feel encouraged to post things like this as they come
>> up. Maybe
>> there could be kind of a pitfalls-page somewhere in the docs collecting
>> these things.
>>
>> Best
>>
>> Stefan
&
On Thu, May 14, 2015 at 11:53 PM, Nathaniel Smith wrote:
> On Thu, May 14, 2015 at 9:29 PM, Guido van Rossum wrote:
>> I expect you can make something that behaves like list by defining __mul__
>> and __rmul__ and returning NotImplemented.
>
> Hmm, it's fairly tricky
On Sat, May 16, 2015 at 1:31 AM, Nick Coghlan wrote:
> On 16 May 2015 at 07:35, Nathaniel Smith wrote:
>> On Thu, May 14, 2015 at 11:53 PM, Nathaniel Smith wrote:
>>> On Thu, May 14, 2015 at 9:29 PM, Guido van Rossum wrote:
>>>> I expect you can make somet
On Fri, Sep 8, 2017 at 12:13 PM, Antoine Pitrou wrote:
> On Fri, 08 Sep 2017 12:04:10 -0700
> Benjamin Peterson wrote:
>> I like it overall.
>>
>> - I was wondering what happens during interpreter shutdown. I see you
>> have that listed as a open issue. How about simply shutting down the
>> final
On Fri, Sep 8, 2017 at 1:45 PM, Ethan Furman wrote:
> On 09/08/2017 12:44 PM, Larry Hastings wrote:
>
>> I've updated PEP 549 with a new title--"Instance Descriptors" is a better
>> name than "Instance Properties"--and to
>> clarify my rationale for the PEP. I've also updated the prototype with
>
On Fri, Sep 8, 2017 at 8:54 PM, Michel Desmoulin
wrote:
>
> Le 09/09/2017 à 01:28, Stefan Krah a écrit :
>> Still, the argument "who uses subinterpreters?" of course still remains.
>
> For now, nobody. But if we expose it and web frameworks manage to create
> workers as fast as multiprocessing and
On Sep 9, 2017 9:07 AM, "Nick Coghlan" wrote:
To immediately realise some level of efficiency benefits from the
shared memory space between the main interpreter and subinterpreters,
I also think these low level FIFOs should be defined as accepting any
object that supports the PEP 3118 buffer pro
On Sep 8, 2017 4:06 PM, "Eric Snow" wrote:
run(code):
Run the provided Python code in the interpreter, in the current
OS thread. If the interpreter is already running then raise
RuntimeError in the interpreter that called ``run()``.
The current interpreter (which ca
On Sun, Sep 10, 2017 at 12:06 PM, Barry Warsaw wrote:
> For PEP 553, I think it’s a good idea to support the environment variable
> $PYTHONBREAKPOINT[*] but I’m stuck on a design question, so I’d like to get
> some feedback.
>
> Should $PYTHONBREAKPOINT be consulted in breakpoint() or in
> sys.
Hi Eric,
A few quick comments:
Why do you even have a hash= argument on individual fields? For the whole
class, I can imagine you might want to explicitly mark a whole class as
unhashable, but it seems like the only thing you can do with the
field-level hash= argument is to create a class where t
On Mon, Sep 11, 2017 at 5:32 AM, Eric V. Smith wrote:
> On 9/10/17 11:08 PM, Nathaniel Smith wrote:
>>
>> Hi Eric,
>>
>> A few quick comments:
>>
>> Why do you even have a hash= argument on individual fields? For the
>> whole class, I can imagine you m
On Mon, Sep 11, 2017 at 5:27 PM, Barry Warsaw wrote:
> On Sep 10, 2017, at 13:46, Nathaniel Smith wrote:
>>
>> On Sun, Sep 10, 2017 at 12:06 PM, Barry Warsaw wrote:
>>> For PEP 553, I think it’s a good idea to support the environment variable
>>> $PYTHONBREAKP
On Mon, Sep 11, 2017 at 6:45 PM, Barry Warsaw wrote:
> On Sep 11, 2017, at 18:15, Nathaniel Smith wrote:
>
>> Compared to checking it on each call to sys.breakpointhook(), I guess
>> the two user-visible differences in behavior would be:
>>
>> - whether mutatin
On Wed, Sep 13, 2017 at 11:49 AM, Guido van Rossum wrote:
> > Why not adding both? Properties do have their uses as does __getattr__.
>
> In that case I would just add __getattr__ to module.c, and add a recipe or
> perhaps a utility module that implements a __getattr__ you can put into your
> mod
On Sep 13, 2017 9:01 PM, "Nick Coghlan" wrote:
On 14 September 2017 at 11:44, Eric Snow
wrote:
>send(obj):
>
>Send the object to the receiving end of the channel. Wait until
>the object is received. If the channel does not support the
>object then TypeError is raise
On Thu, Sep 14, 2017 at 5:44 PM, Nick Coghlan wrote:
> On 14 September 2017 at 15:27, Nathaniel Smith wrote:
>> I don't get it. With bytes, you can either share objects or copy them and
>> the user can't tell the difference, so you can change your mind later if you
&g
On Sep 18, 2017 07:58, "Antoine Pitrou" wrote:
Le 18/09/2017 à 16:52, Guido van Rossum a écrit :
>
> In Python 2 the traceback was not part of the exception object because
> there was (originally) no cycle GC. In Python GC we changed the awkward
> interface to something more useful, because we c
On Mon, Sep 18, 2017 at 9:50 AM, Antoine Pitrou wrote:
> On Mon, 18 Sep 2017 09:42:45 -0700
> Nathaniel Smith wrote:
>>
>> Obviously it's nice when the refcount system is able to implicitly clean
>> things up in a prompt and deterministic way, but there are already
On Mon, Sep 18, 2017 at 10:59 AM, Antoine Pitrou wrote:
> Le 18/09/2017 à 19:53, Nathaniel Smith a écrit :
>>>
>>>> Why are reference cycles a problem that needs solving?
>>>
>>> Because sometimes they are holding up costly resources in memory when
>&
On Sat, Sep 23, 2017 at 2:45 AM, Antoine Pitrou wrote:
>> As to "running_interpreters()" and "idle_interpreters()", I'm not sure
>> what the benefit would be. You can compose either list manually with
>> a simple comprehension:
>>
>> [interp for interp in interpreters.list_all() if interp.is_
On Sun, Oct 1, 2017 at 7:04 PM, INADA Naoki wrote:
> 4. http.client
>
> import time: 1376 | 2448 | email.header
> ...
> import time: 1469 | 7791 | email.utils
> import time: 408 | 10646 | email._policybase
> impor
On Sun, Oct 15, 2017 at 6:33 PM, Yury Selivanov wrote:
> Hi,
>
> It looks like the discussion about the execution context became
> extremely hard to follow. There are many opinions on how the spec for
> generators should look like. What seems to be "natural"
> behaviour/example to one, seems to
On Sun, Oct 15, 2017 at 10:10 PM, Guido van Rossum wrote:
> On Sun, Oct 15, 2017 at 8:17 PM, Nathaniel Smith wrote:
>>
>> On Sun, Oct 15, 2017 at 6:33 PM, Yury Selivanov
>> wrote:
>> > Stage 1. A new execution context PEP to solve the problem *just for
>>
On Mon, Oct 16, 2017 at 11:12 AM, Ethan Furman wrote:
> What would be really nice is to have attribute access like thread locals.
> Instead of working with individual ContextVars you grab the LocalContext and
> access the vars as attributes. I don't recall reading in the PEP why this
> is a bad i
On Mon, Oct 16, 2017 at 8:49 AM, Guido van Rossum wrote:
> On Sun, Oct 15, 2017 at 10:26 PM, Nathaniel Smith wrote:
>>
>> On Sun, Oct 15, 2017 at 10:10 PM, Guido van Rossum
>> wrote:
>> > Yes, that's what I meant by "ignoring generators". And I&#x
On Oct 17, 2017 11:25 AM, "Guido van Rossum" wrote:
In short, I really don't think there's a need for context variables to be
faster than instance variables.
There really is: currently the cost of looking up a thread local through
the C API is a dict lookup, which is faster than instance varia
On Thu, Oct 26, 2017 at 3:42 PM, Ethan Smith wrote:
> However, the stubs may be put in a sub-folder
> of the Python sources, with the same name the ``*.py`` files are in. For
> example, the ``flyingcircus`` package would have its stubs in the folder
> ``flyingcircus/flyingcircus/``. This path is c
On Nov 5, 2017 2:41 PM, "Paul Ganssle" wrote:
I think the question of whether any specific implementation of dict could
be made faster for a given architecture or even that the trade-offs made by
CPython are generally the right ones is kinda beside the point. It's
certainly feasible that an imple
On Sun, Nov 5, 2017 at 9:38 PM, Nick Coghlan wrote:
> We've been running the current experiment for 7 years, and the main
> observable outcome has been folks getting surprised by breaking
> changes in CPython releases, especially folks that primarily use
> Python interactively (e.g. for data analy
On Nov 7, 2017 06:24, "Nick Coghlan" wrote:
On 7 November 2017 at 19:30, Paul Moore wrote:
> On 7 November 2017 at 04:09, Nick Coghlan wrote:
>> Given the status quo, how do educators learn that the examples they're
>> teaching to their students are using deprecated APIs?
>
> By reading the doc
On Nov 7, 2017 12:02 PM, "Barry Warsaw" wrote:
On Nov 7, 2017, at 09:39, Paul Sokolovsky wrote:
> So, the problem is that there's no "Python language spec”.
There is a language specification: https://docs.python.org/3/refe
rence/index.html
But there are still corners that are undocumented, or
On Thu, Nov 9, 2017 at 1:46 PM, Cameron Simpson wrote:
> On 08Nov2017 10:28, Antoine Pitrou wrote:
>>
>> 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
On Nov 8, 2017 16:12, "Nick Coghlan" wrote:
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:
>>
>>
On Tue, Nov 7, 2017 at 8:45 AM, Nathaniel Smith wrote:
> Also, IIRC it's actually impossible to set the stacklevel= correctly when
> you're deprecating a whole module and issue the warning at import time,
> because you need to know how many stack frames the import system u
On Fri, Nov 10, 2017 at 11:34 PM, Brett Cannon wrote:
> On Thu, Nov 9, 2017, 17:33 Nathaniel Smith, wrote:
>> - if an envvar CI=true is set, then by default make deprecation warnings
>> into errors. (This is an informal standard that lots of CI systems use.
>> Error inst
On Sun, Nov 12, 2017 at 1:24 AM, Nick Coghlan wrote:
> This change will lead to DeprecationWarning being displayed by default for:
>
> * code executed directly at the interactive prompt
> * code executed directly as part of a single-file script
Technically it's orthogonal, but if you're trying to
On Sun, Nov 12, 2017 at 11:21 AM, Ethan Smith wrote:
>
>
> On Sun, Nov 12, 2017 at 9:53 AM, Jelle Zijlstra
> wrote:
>>
>> 2017-11-12 3:40 GMT-08:00 Ethan Smith :
>>> The name of the stub
>>> package
>>> MUST follow the scheme ``pkg_stubs`` for type stubs for the package named
>>> ``pkg``. The nor
Can you give any examples of problems caused by the ast not being
standardized? The original motivation of being able to distinguish between
foo(x: int)
foo(x: "int")
isn't very compelling – it's not clear it's a problem in the first place,
and even if it is then all we need is some kind of boo
On Mon, Nov 13, 2017 at 6:09 AM, Serhiy Storchaka wrote:
> 13.11.17 14:29, Antoine Pitrou пише:
>>
>> On Mon, 13 Nov 2017 22:37:46 +1100
>> Chris Angelico wrote:
>>>
>>> On Mon, Nov 13, 2017 at 9:46 PM, Antoine Pitrou
>>> wrote:
>>>>
On Wed, Nov 15, 2017 at 4:27 PM, Ethan Furman wrote:
> The second way is fairly similar, but instead of replacing the entire
> sys.modules entry, its class is updated to be the class just created --
> something like sys.modules['mymod'].__class__ = MyNewClass .
>
> My request: Can someone write a
On Wed, Nov 15, 2017 at 5:49 PM, Guido van Rossum wrote:
>> If not, why not, and if so, shouldn't PEP 562's __getattr__ also take a
>> 'self'?
>
> Not really, since there's only one module (the one containing the
> __getattr__ function). Plus we already have a 1-argument module-level
> __getattr__
On Wed, Nov 15, 2017 at 10:14 PM, Nathaniel Smith wrote:
> On Wed, Nov 15, 2017 at 4:27 PM, Ethan Furman wrote:
>> The second way is fairly similar, but instead of replacing the entire
>> sys.modules entry, its class is updated to be the class just created --
>> something li
On Sun, Nov 19, 2017 at 2:26 AM, Serhiy Storchaka wrote:
> It seems to me that most of issues with FutureWarning on GitHub [1] are
> related to NumPy and pandas which use FutureWarning for its original nominal
> purpose, for warning about using programming interfaces that will change the
> behavio
On Fri, Nov 24, 2017 at 4:22 PM, Guido van Rossum wrote:
> The more I hear about this topic, the more I think that `await`, `yield` and
> `yield from` should all be banned from occurring in all comprehensions and
> generator expressions. That's not much different from disallowing `return`
> or `br
On Fri, Nov 24, 2017 at 9:04 PM, Nick Coghlan wrote:
> def example():
> comp1 = yield from [(yield x) for x in ('1st', '2nd')]
> comp2 = yield from [(yield x) for x in ('3rd', '4th')]
> return comp1, comp2
Isn't this a really confusing way of writing
def example():
On Fri, Nov 24, 2017 at 9:39 PM, Nick Coghlan wrote:
> On 25 November 2017 at 15:27, Nathaniel Smith wrote:
>> On Fri, Nov 24, 2017 at 9:04 PM, Nick Coghlan wrote:
>>> def example():
>>> comp1 = yield from [(yield x) for x in ('1st', '2nd&#
On Sat, Nov 25, 2017 at 3:37 PM, Guido van Rossum wrote:
> On Sat, Nov 25, 2017 at 1:05 PM, David Mertz wrote:
>>
>> FWIW, on a side point. I use 'yield' and 'yield from' ALL THE TIME in real
>> code. Probably 80% of those would be fine with yield statements, but a
>> significant fraction use `ge
On Sun, Nov 26, 2017 at 9:33 PM, Caleb Hattingh
wrote:
> The PEP only says that __await__ must return an iterator, but it turns out
> that it's also required that that iterator
> should not return any intermediate values.
I think you're confused :-). When the iterator yields an intermediate
value
On Nov 28, 2017 3:55 PM, "Guido van Rossum" wrote:
On Sun, Nov 19, 2017 at 5:40 AM, Nathaniel Smith wrote:
> Eh, numpy does use FutureWarning for changes where the same code will
> transition from doing one thing to doing something else without
> passing through a state
On Dec 7, 2017 12:49, "Eric V. Smith" wrote:
The reason I didn't include it (as @dataclass(slots=True)) is because it
has to return a new class, and the rest of the dataclass features just
modifies the given class in place. I wanted to maintain that conceptual
simplicity. But this might be a reas
On Tue, Dec 12, 2017 at 10:39 PM, Dima Tisnek wrote:
> My 2c:
> TL;DR PEP specifies implementation in some detail, but doesn't show
> how proposed change can or should be used.
>
>
>
> get()/set(value)/delete() methods: Python provides syntax sugar for
> these, let's use it.
> (dict: d["k"]/d["k]
On Dec 14, 2017 21:30, "Raymond Hettinger"
wrote:
> On Dec 14, 2017, at 6:03 PM, INADA Naoki wrote:
>
> If "dict keeps insertion order" is not language spec and we
> continue to recommend people to use OrderedDict to keep
> order, I want to optimize OrderedDict for creation/iteration
> and mem
On Dec 15, 2017 10:50, "Tim Peters" wrote:
[Eric Snow ]
> Does that include preserving order after deletion?
Given that we're blessing current behavior:
- At any moment, iteration order is from oldest to newest. So, "yes"
to your question.
- While iteration starts with the oldest, .popitem()
On Dec 16, 2017 11:44 AM, "Guido van Rossum" wrote:
On Sat, Dec 16, 2017 at 11:14 AM, Antoine Pitrou
wrote:
> On Sat, 16 Dec 2017 19:37:54 +0100
> Antoine Pitrou wrote:
> >
> > Currently, you can pass a `module_api_version` to PyModule_Create2(),
> > but that function is for specialists only :
On Mon, Dec 18, 2017 at 7:02 PM, Barry Warsaw wrote:
> On Dec 18, 2017, at 21:11, Chris Barker wrote:
>
>> Will changing pprint be considered a breaking change?
>
> Yes, definitely.
Wait, what? Why would changing pprint (so that it accurately reflects
dict's new underlying semantics!) be a break
On Mon, Dec 18, 2017 at 7:58 PM, Steven D'Aprano wrote:
> On Mon, Dec 18, 2017 at 07:37:03PM -0800, Nathaniel Smith wrote:
>> On Mon, Dec 18, 2017 at 7:02 PM, Barry Warsaw wrote:
>> > On Dec 18, 2017, at 21:11, Chris Barker wrote:
>> >
>> >> Will cha
On Mon, Dec 18, 2017 at 11:38 PM, Steve Dower wrote:
> On 18Dec2017 2309, Steven D'Aprano wrote:
>> [A LOT OF THINGS I AGREE WITH]
> I agree completely with Steven's reasoning here, and it bothers me that
> what is an irrelevant change to many users (dict becoming ordered) seems
> to imply that al
On Tue, Dec 19, 2017 at 4:56 PM, Steve Dower wrote:
> On 19Dec2017 1004, Chris Barker wrote:
>>
>> Nathaniel Smith has pointed out that eval(pprint(a_dict)) is supposed to
>> return the same dict -- so documented behavior may already be broken.
>
>
> Two relevant
On Thu, Dec 28, 2017 at 1:51 AM, Victor Stinner
wrote:
> var = ContextVar('var', default=42)
>
> and:
>
> var = ContextVar('var')
> var.set (42)
>
> behaves the same, no?
No, they're different. The second sets the value in the current
context. The first sets the value in all contexts that current
On Fri, Dec 29, 2017 at 12:30 PM, Ethan Furman wrote:
> Good point. So auto-generate a new __repr__ if:
>
> - one is not provided, and
> - existing __repr__ is either:
> - object.__repr__, or
> - a previous dataclass __repr__
>
> And if the auto default doesn't work for one's use-case, use th
On Sat, Dec 30, 2017 at 7:26 AM, Stephen J. Turnbull
wrote:
> Christian Heimes writes:
> > Questions:
> > - Is everybody OK with breaking backwards compatibility? The risk is
> > small. ASCII-only domains are not affected
>
> That's not quite true, as your German example shows. In some Orienta
On Sat, Dec 30, 2017 at 2:28 AM, Antoine Pitrou wrote:
> On Fri, 29 Dec 2017 21:54:46 +0100
> Christian Heimes wrote:
>>
>> On the other hand ssl module is currently completely broken. It converts
>> hostnames from bytes to text with 'idna' codec in some places, but not
>> in all. The SSLSocket.s
On Dec 31, 2017 7:37 AM, "Stephen J. Turnbull" <
turnbull.stephen...@u.tsukuba.ac.jp> wrote:
Nathaniel Smith writes:
> Issue 1: Python's built-in IDNA implementation is wrong (implements
> IDNA 2003, not IDNA 2008).
Is "wrong" the right word here? I&#x
On Sun, Dec 31, 2017 at 5:39 PM, Steven D'Aprano wrote:
> On Sun, Dec 31, 2017 at 09:07:01AM -0800, Nathaniel Smith wrote:
>
>> This is another reason why we ought to let users do their own IDNA handling
>> if they want...
>
> I expect that letting users do their own
1 - 100 of 441 matches
Mail list logo
