ists, however, and so having it handy would
be nice.
| From: Greg Ewing <[EMAIL PROTECTED]>
| Smith wrote:
|
|| When teaching some programming to total newbies, a common
|| frustration is how to explain why a==b is False when a and b are
|| floats computed by different routes wh
et the comparison to 12-digit default precision or arbitrary precision with
optional arguments, e.g. to 3 digits of precision:
trim(a,3) < trim(b,3)
>From a search on the documentation, I don't see that the name trim() is taken
>yet.
OK, comments responding to Greg follow.
| From:
A problem that I pointed out with the proposed areclose() function is that it
has within it a fp comparison. If such a function is to have greater utility,
it should allow the user to specify how significant to consider the computed
error. A natural extension of being able to tell if 2 fp number
Raymond Hettinger wrote:
| [Chris Smith]
|| Does it help to spell it like this?
||
|| def areclose(x, y, relative_err = 1.e-5, absolute_err=1.e-8):
|| diff = abs(x - y)
|| ave = (abs(x) + abs(y))/2
|| return diff < absolute_err or diff/ave < relative_err
|
| There is a certain
I just ran into a curious behavior with small floating points, trying to find
the limits of them on my machine (XP). Does anyone know why the '0.0' is
showing up for one case below but not for the other? According to my tests, the
smallest representable float on my machine is much smaller than 1
| From: Michael Hudson <[EMAIL PROTECTED]>
| Guido van Rossum <[EMAIL PROTECTED]> writes:
|
|| On 2/8/06, Patrick Collison <[EMAIL PROTECTED]> wrote:
||| And to think that people thought that keeping "lambda", but changing
||| the name, would avoid all the heated discussion... :-)
||
|| Note that
I'm wondering if it's just "foolish consistency" (to quote a PEP 8) that is
calling for the dropping of <> in preference of only !=. I've used the former
since the beginning in everything from basic, fortran, claris works, excel,
gnumeric, and python. I tried to find a rationale for the dropping
I've been thinking
about a function that was recently proposed at python-dev named 'areclose'.
It is a function that is meant to tell whether two (or possible more) numbers
are close to each other. It is a function similar to one that exists in
Numeric. One such implementation is
def
arec
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
My team has a python app that appears to perform 10+% better when the
python source is present v.s. when only the pyc's are distributed. This is
contradictory to my understanding of how python leverages pyc's.
Scenario
1. pyc-only install sees mediocre performance. (pyc's are built using
compile
seem to have posted the build recipe for the
toolchain itself -- I'm sure he'd be happy to if you asked though.)
AFAICT the end result is a single free compiler toolchain that can
spit out 32- and 64-bit binaries using whichever MSVC runtime you
prefer.
-n
--
Nathaniel J. Smith
Po
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
just to work around this bug, or whether they do it for
> other reasons as well (but I suspect the latter).
numpy.distutils is a massive pile of hacks to handle all kinds of
weird things including recursive builds, fortran, runtime capability
detection (like autoconf), and every random issue any
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
etuptools.
>>> - For 32 bit Python 3.2-3.4, install Visual Studio Express and
>>> everything just works.
>>> - For 64 bit Python 3.2-3.4, install the SDK, set some environment
>>> variables, and everything just works.
I think the SDK covers both 32 and 64 bit? If
ss A:' with 'class A(object):' then you'll see the same
behaviour on both py2 and py3.)
Easy workaround:
def __call__(self, *args, **kwargs):
return self._my_call(*args, **kwargs)
Now you can assign a._my_call to be whatever you want.
-n
--
Nathaniel J. Smith
Postdoctora
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.
>
>
Option 3
*really* fails is for compiled modules with PEP 3121 metadata, and
compiled modules can already use a module subclass via other means
(since they instantiate their own module objects).
Thoughts? Suggestions on other options I've missed? Should I go ahead
and write
3 are pretty nice at the language level! Most
Python objects allow assignment to __class__ and __dict__, and both
PyPy and Jython at least do support __class__ assignment. Really the
only downside with Option 1 is that actually implementing it requires
attention from someo
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
g correctly the
slightly weird class vs. instance lookup rules for special methods,
you can write a module subclass like
class GetAttrModule(types.ModuleType):
def __getattr__(self, name):
return self.__dict__["__getattr__"](name)
and then use ctypes hacks to get it into sys.modules[_
jects during shutdown.
I guess it also has the mild limitation that it doesn't work with
extension modules, but eh. Mostly I'd be nervous about the two points
above.
-n
--
Nathaniel J. Smith
Postdoctoral researcher - Informatics - University of Edinburgh
http://vorpus.org
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
of methods as one or both of these
objects, or possibly inherits from a certain abstract base class. It
would be useful to have some terms to refer specifically to async def
functions and the await protocol as opposed to generators and the
iterator protocol, and
care
about the exact details all that much. What I do feel strongly about
is that whatever syntax we end up with, there should be *some*
accurate human-readable description of *what it is*. AFAICT the PEP
currently doesn't have that.
-n
--
Nathaniel J. Smith -- http://vorpus.org
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
hon 'list' is a weird type with
undocumented behaviour that you can't actually define using pure
Python code.
Should I be worried?
-n
[1] https://github.com/numpy/numpy/pull/5864
[2] https://github.com/numpy/numpy/issues/5844
--
Nathaniel J. Smith -- http://vorpus.org
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
nding the scope of your proposal. Feel free to throw
things at me or whatever.
Would it make sense to also move signal handlers to run in this
thread? Those are the other major source of nasty re-entrancy
problems.
-n
--
Nathaniel J. Smith -- https://vorpus.org
_
ky to switch to that form --
don't think of toy examples, think of django/__init__.py or
numpy/__init__.py. You have to rewrite the whole export logic, and you
have to figure out what to do with things like submodules that import
from the parent module before the swaparoo happens, you can get
and -- on Unix -- slower to
start than either of them (no fork).
-n
--
Nathaniel J. Smith -- https://vorpus.org
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/
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
akpoint() or in
> sys.breakpointhook()?
Wouldn't the usual pattern be to check $PYTHONBREAKPOINT once at
startup, and if it's set use it to initialize sys.breakpointhook()?
Compare to, say, $PYTHONPATH.
-n
--
Nathaniel J. Smith -- https://vorpus.org
__
m ordering methods (lt/gt/...).
Maybe the cmp= argument should take an enum with options
none/equality-only/full?
The "why not attrs" section kind of reads like "because it's too popular
and useful"?
-n
On Sep 8, 2017 08:44, "Eric V. Smith" wrote:
Oops, I
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
om
module_helper.property_emulation import __getattr__' it'd be 'from
module_helper import enable_property_emulation;
enable_property_emulation(__name__)'. Still has the slowdown problem
but it would work.
-n
--
Nathaniel J. Smith -- https://vorpus.org
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
>&
ing at the same time" ("this thing" can be something such as disk
> I/O).
It's fairly reasonable to implement a mutex using a CSP-style
unbuffered channel (send = acquire, receive = release). And the same
trick turns a channel with a fixed-size buffer into a bounded
semaph
exception object that just holds the string, and then compiles
and caches it the first time it's used. Might be tricky to do in a
backwards compatibility way if it moves detection of invalid regexes
from compile time to use time, but it could be an opt-in flag.
-n
--
Nathaniel J. Smith -
you access the ThreadState's
context dict (or rather, an opaque ContextState object that holds the
context dict), and then task schedulers can call them at appropriate
moments.
-n
--
Nathaniel J. Smith -- https://vorpus.org
___
Python-Dev mailing list
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
>>
ent dict when switching tasks and clone it when starting a new
task, but those are the only absolutely necessary operations.
-n
--
Nathaniel J. Smith -- https://vorpus.org
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailma
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
Information V3
The live version is here: https://www.python.org/dev/peps/pep-0561/
As always, duplicated below.
Ethan Smith
---
PEP: 561
Title: Distributing and Packaging Type Information
Author: Ethan Smith
Status: Draft
Type: Standards Track
On Thu, Oct 26, 2017 at 4:48 PM, Mariatta Wijaya
wrote:
> Not sure if postings to python-ideas count,
>
>
> PEP 1 says:
>
> Post-History is used to record the dates of when new versions of the PEP
> are posted to python-list and/or python-dev.
>
> So, no ?
>
Reading PEP 12, https://www.python.o
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/``.
On Fri, Oct 27, 2017 at 12:44 AM, Nathaniel Smith wrote:
> 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`` p
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
y one issuing deprecation warnings. I'm thinking in
particular of the filter-based-on-Python-version idea. Maybe you could
have subclasses like Py35DeprecationWarning and filter on those?)
-n
--
Nathaniel J. Smith -- https://vorpus.org
___
Pyth
> Beyond the API already proposed in PEP 557, this would mean adding:
>
> * dataclasses.ClassVar (as proposed above)
> * dataclasses.Any (probably just set to the literal string
> "dataclasses.Any")
> * dataclasses.NamedTuple (as a replacement for typing.NamedTuple)
> * potentially dataclasses.is_c
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
problem when porting apps to PyPy. The common
case is servers that crash because they rely on the GC to close file
descriptors, and then run out of file descriptors. IIRC this is the
major obstacle to supporting OpenStack-on-PyPy. NumPy is currently
going through the process to deprecate and re
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
below.
Cheers,
Ethan Smith
---
PEP: 561
Title: Distributing and Packaging Type Information
Author: Ethan Smith
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 09-Sep-2017
Python-Version: 3.7
Post-History: 10-Sep-2017, 12-Sep
On Sun, Nov 12, 2017 at 9:53 AM, Jelle Zijlstra
wrote:
>
>
> 2017-11-12 3:40 GMT-08:00 Ethan Smith :
>
>> Hello,
>>
>> I re-wrote my PEP to have typing opt-in be per-package rather than
>> per-distribution. This greatly simplifies things, and thanks to the
if you're trying to get better
warnings in the REPL, then you might also want to look at:
https://bugs.python.org/issue1539925
https://github.com/ipython/ipython/issues/6611
-n
--
Nathaniel J. Smith -- https://vorpus.org
___
Python-Dev mailing list
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`` fo
On Sun, Nov 12, 2017 at 8:07 PM, Nathaniel Smith wrote:
> On Sun, Nov 12, 2017 at 11:21 AM, Ethan Smith wrote:
> >
> >
> > On Sun, Nov 12, 2017 at 9:53 AM, Jelle Zijlstra <
> jelle.zijls...@gmail.com>
> > wrote:
> >>
> >> 2017-11-12 3
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 Mon, Nov 13, 2017 at 3:50 PM, Sebastian Rittau
wrote:
> Hello everyone,
>
>
> Am 14.11.2017 um 00:29 schrieb Guido van Rossum:
>
>> This is a nice piece of work. I expect to accept it pretty much verbatim
>> (with some small edits, see https://github.com/python/peps/pull/467). I
>> agree with
A note was added [1] about the solution for module only distributions and
is live on Python.org.
[1] https://github.com/python/peps/pull/468
Ethan Smith
On Tue, Nov 14, 2017 at 1:02 AM, Sebastian Rittau
wrote:
> Am 14.11.2017 um 02:38 schrieb Guido van Rossum:
>
> On Mon, Nov 13, 201
ted attributes to show up in tab completion. For other use
cases like lazy imports, you would implement __dir__ too.)
Example usage:
https://github.com/python-trio/trio/blob/master/trio/__init__.py#L66-L98
-n
--
Nathaniel J. Smith -- https://vorpus.org
___
rt __getattr__, __dir__
auto_import_modules = {"foo", "bar"}
# auto_importer.py
def __getattr__(self, name):
if name in self.auto_import_modules:
...
-n
--
Nathaniel J. Smith -- https://vorpus.org
___
Python-Dev mailing list
Python
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
ough people have
updated their code that the screams die down. I'm pretty sure we'll be
changing our policy at some point, possibly to always use
FutureWarning for everything.
-n
--
Nathaniel J. Smith -- https://vorpus.org
___
Python-Dev mai
ld` and `await` use two separate, unrelated channels. So there's
no confusion or problem with having `await` inside a comprehension.
-n
--
Nathaniel J. Smith -- https://vorpus.org
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/ma
x27;t this a really confusing way of writing
def example():
return [(yield '1st'), (yield '2nd')], [(yield '3rd'), (yield '4th')]
?
-n
--
Nathaniel J. Smith -- https://vorpus.org
___
Python-Dev mailing l
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&#
1 - 100 of 2036 matches
Mail list logo
