that almost everyone actually uses? That's already
broken on every minor release, so you shouldn't spend any time
worrying about preserving compatibility there.
-n
--
Nathaniel J. Smith -- https://vorpus.org
___
Python-Dev mailing l
behaviour
> change.
And if the 64-bit installer could detect 32-bit systems and explain to
users that they got the wrong version and direct them to the correct
one, that would help anyone who does get confused by the 64-bit
installer becoming more prominent.
-n
--
Nathaniel J. Smith -- h
g Python's
quality is always welcome. Just be careful that it's actually helpful
:-).
-n
--
Nathaniel J. Smith -- https://vorpus.org
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscri
On Mon, Jul 23, 2018, 08:22 Eric Le Lay wrote:
> Hello list,
>
> I encountered a problem with the Windows packaging of gPodder[1]
> using msys2:
>
> basic libraries (zlib, openssl) depended upon by python
> platform-specific modules are loaded preferably :
> 1. from lib-dynload (where they are n
Hi Wes,
It's great you're passionate about python security, but this is the wrong
way to go about it. Spectre is inherently super subtle and confusing, so if
there's something that people need to do, then we need a clear,
comprehensive write-up of what the threat is and how to address it. Perhaps
What information do you wish the interpreter provided, that would make your
program simpler and more reliable?
On Fri, Sep 28, 2018, 07:21 Gabriele wrote:
> Hi Victor,
>
> > I understand that you are writing a debugger and you can only *read*
> > modify, not execute code, right?
>
> I'm working
On Fri, Sep 28, 2018 at 3:29 PM, Gabriele wrote:
> On Fri, 28 Sep 2018 at 23:12, Nathaniel Smith wrote:
>> What information do you wish the interpreter provided, that would make your
>> program simpler and more reliable?
>
> An exported global variable that poin
might also solve your problem, if pool.map is clever enough
to only send the function object once to each worker?
-n
--
Nathaniel J. Smith -- https://vorpus.org
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/lis
On Fri, Oct 12, 2018, 06:09 Antoine Pitrou wrote:
> On Fri, 12 Oct 2018 08:33:32 -0400
> Sean Harrington wrote:
> > Hi Nathaniel - this if this solution can be made performant, than I would
> > be more than satisfied.
> >
> > I think this would require removing "func" from the "task tuple", and
waiting for instructions (continue / enter debugger / exit /
...).
Or, on Linux, there's: https://www.criu.org/
I also wonder if it would be useful to give pdb the ability to break
when an exception is *raised*, rather than when it's caught?
-n
).run_until_complete(await_things())
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/njs%40pob
g the C API larger and more
complicated, rather than simplifying it? You cite some benefits
(tagged pointers, changing the layout of PyObject, making PyPy's life
easier), but I don't see how you can do any of those things so long as
the current C API remain
On Fri, Nov 9, 2018 at 6:03 PM, Victor Stinner wrote:
> Le sam. 10 nov. 2018 à 02:50, Nathaniel Smith a écrit :
>> Doesn't this mean that you're just making the C API larger and more
>> complicated, rather than simplifying it? You cite some benefits
>> (tagged p
I don't think any real libm even
tries to set all the status flags correctly. And I'm not sure sNaN
support is actually useful anyway...
Of course if all you want is a value that raises an exception whenever
it's used in an arithmetic expression, then Python does support that
:-)
On Mon, Nov 12, 2018 at 10:46 PM, Gregory P. Smith wrote:
>
> On Fri, Nov 9, 2018 at 5:50 PM Nathaniel Smith wrote:
>>
>> On Fri, Nov 9, 2018 at 4:30 PM, Victor Stinner
>> wrote:
>> > Ah, important points. I don't want to touch the current C AP
the huge benefit that
you can actually experiment and try things out without committing to
supporting them forever.
And I don't know the best answer to all your questions above, that's
what experimenting is for :-). But it certainly is technically
possible
said,
> it is a high risk project with many PRs going directly into master, so it
> does warrant having buy in that the churn isn't destabilizing and will
> actually produce a benefit that is worth it.
>
>
> Raymond
>
>
>
>
>
>
>
>
use Py_LIMITED_API. I'm guessing it's
partly due to limits of the API, but also things like: lack of docs
and examples, lack of py2 support, ...
-n
--
Nathaniel J. Smith -- https://vorpus.org
___
Python-Dev mailing list
Python-Dev@python.org
h
On Sun, Nov 18, 2018 at 8:52 AM Stefan Behnel wrote:
>
> Gregory P. Smith schrieb am 15.11.18 um 01:03:
> > From my point of view: A static inline function is a much nicer modern code
> > style than a C preprocessor macro.
>
> It's also slower to compile, given that f
BI with every feature release – at least for the
main ABI. The limited ABI supposedly doesn't, but probably does, and
as noted above it has such limited use that it's probably still
possible to fix any stuff that's leaked out accidentally.
-n
--
Nathaniel J. Smith -- https://vorpus.
and Oracle is throwing a lot of money at Graal so I
guess we'll find out.
--
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/mailman/options/python-dev/archive%40mail-archive.com
On Mon, Nov 26, 2018 at 6:12 PM Eric V. Smith wrote:
> I thought the important part of the proposal was to have multiple
> PyHandles that point to the same PyObject (you couldn't "directly
> compare handles with each other to learn about object identity"). But
> I
On Wed, Nov 28, 2018, 12:08 Antoine Pitrou On Wed, 28 Nov 2018 19:35:31 +
> Jonathan Underwood wrote:
> > On Wed, 28 Nov 2018 at 18:57, Antoine Pitrou
> wrote:
> > >
> > > On Wed, 28 Nov 2018 10:43:04 -0800
> > > "Gregory P. Smith" wrote:
&
On Thu, Nov 29, 2018, 08:34 Antoine Pitrou
> Le 29/11/2018 à 17:25, Steve Dower a écrit :
> >
> > My experience is that the first group would benefit from a larger
> > _standard distribution_, which is not necessarily the same thing as a
> > larger stdlib.
> >
> > I'm firmly on the "smaller core,
On Thu, Nov 29, 2018, 10:32 Antoine Pitrou On Thu, 29 Nov 2018 09:49:32 -0800
> Nathaniel Smith wrote:
> >
> > There are a lot of challenges to switching to a "standard distribution"
> > model. I'm not certain it's the best option. But what I like about i
probably true. But for the major projects where I have some
knowledge of the development process -- like requests, urllib3, numpy,
pip, setuptools, cryptography -- the main blocker to putting them in
the stdlib is that the maintainers don't think a stdlibized version
could meet their quality
r core
strengths like the language and interpreter. But if the stdlib isn't a
single-box-of-batteries, then what is it?
It's really hard to tell whether specific packages would be good or
bad additions to the stdlib, when we don't even know what the stdlib
is supposed to be.
-n
--
On Sat, Dec 1, 2018, 06:56 Steve Holden We* should probably do more collectively to point people at
> production-quality third-party modules, as I believe we currently do with
> pipenv which, while not a part of the standard library, is still
> recommended in the documentation as the preferred met
Travis is in the middle of moving everything from AWS to GCE, which is
probably related:
https://blog.travis-ci.com/2018-11-19-required-linux-infrastructure-migration
As noted there, GCE has different IP addresses. But I suspect it's not the
new IP address that's the problem, but rather the fact
On Tue, Dec 11, 2018, 07:13 Antoine Pitrou
> What you are proposing here starts to smell like an anti-pattern to
> me. Python _is_ a garbage-collected language, so by definition, there
> _are_ going to be resources that are automatically collected when an
> object disappears. If I'm allocating a
n Thu, Jan 17, 2019 at 4:51 PM Gregory P. Smith wrote:
>
> I've heard that libraries using ctypes, cffi, or cython code of various sorts
> in the real world wild today does abuse the unfortunate side effect of
> CPython's implementation of id(). I don't have sp
On Thu, Jan 17, 2019, 22:11 Steve Dower For everyone who managed to reply *hours* after Eryk Sun posted the
> correct answer and still get it wrong, here it is again in full.
>
> As a bonus, here's a link to the place where this answer appears in the
> documentation:
> https://docs.python.org/3/li
7;s some other alternative that people
could use in theory.
-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/mailman/options/python-dev/archive%40mail-archive.com
There are currently numerous incompatibilities between numpy and
subinterpreters, and no concrete plan for fixing them. The numpy team does
not consider subinterpreters to be a supported configuration, and can't
help you with any issues you run into. I know the concept of
subinterpreters is really
ble to assemble
them into a single coherent environment.
-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/mailman/options/python-dev/archive%40mail-archive.com
On Sun, Jan 27, 2019, 06:34 Stephan Reiter Cool. Thanks, Nick!
>
> I did experiments based on this idea (
> https://github.com/stephanreiter/cpython/commit/3bca91c26ac81e517b4aa22302be1741b3315622)
> and haven't rejected it yet. :-)
>
> Together with the other fix (
> https://github.com/stephanrei
r,
> and has a much cleaner looking repr.
How viable would it be to make OrderedDict smaller, faster, and give
it a cleaner looking repr?
-n
--
Nathaniel J. Smith -- https://vorpus.org
___
Python-Dev mailing list
Python-Dev@python.org
https://mai
On Thu, Jan 31, 2019, 05:26 Nick Coghlan On Thu, 31 Jan 2019 at 16:40, Glenn Linderman
> wrote:
> >> On 1/30/2019 8:45 PM, Raymond Hettinger wrote:
> >>> On Jan 30, 2019, at 3:41 PM, Glenn Linderman
> wrote:
> >>> Would it be practical to add deprecated methods to regular dict for
> the OrderedD
l? I guess whether it's pip/pip3/python -m
pip/python3 -m pip would be nice to know. I don't know if
sys.executable would tell us anything useful or not. pip knows where
the current python's script directory is; maybe it should report
whether it contains &#
On Thu, Feb 14, 2019 at 12:43 AM Antoine Pitrou wrote:
>
> On Wed, 13 Feb 2019 17:32:44 -0800
> Nathaniel Smith wrote:
> > On Wed, Feb 13, 2019 at 3:02 PM Steven D'Aprano wrote:
> > >
> > > On Wed, Feb 13, 2019 at 05:16:54PM -0500, Terry Reedy wrote:
>
I noticed that your list doesn't include "add a DOM equality operator".
That seems potentially simpler to implement than canonical XML
serialization, and like a useful thing to have in any case. Would it make
sense as an option?
On Mon, Mar 18, 2019, 15:46 Raymond Hettinger
wrote:
> We're having
suffix)
The choice of ENTROPY_BYTES is an interesting question. 16 (= 128
bits) would be a nice "obviously safe" number, and gives 22-byte
filenames. We might be able to get away with fewer, if we had a
plausible cost model for the attack. This is another point where a
security speci
That does sound strange. How easily can you reproduce it? That majorly
effects how I would try to debug something like this...
If you're able to get an strace of a failed run then that would probably
tell us a *lot*.
On Fri, Mar 29, 2019, 16:28 Steve Dower wrote:
> Hi
>
> I'm trying to track do
On Wed, Apr 10, 2019, 04:04 Victor Stinner wrote:
> Le mar. 9 avr. 2019 à 22:16, Steve Dower a écrit
> :
> > What are the other changes that would be required?
>
> I don't know.
>
> > And is there another
> > way to get the same functionality without ABI modifications?
>
> Py_TRACE_REFS is a dou
On Wed, Apr 10, 2019 at 1:50 PM Steve Dower wrote:
>
> On 10Apr2019 1227, Nathaniel Smith wrote:
> > On Wed, Apr 10, 2019, 04:04 Victor Stinner > <mailto:vstin...@redhat.com>> wrote:
> > I don't think that I ever used sys.getobjects(), whereas many projects
.
-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/mailman/options/python-dev/archive%40mail-archive.com
On Thu, Apr 11, 2019 at 8:26 AM Steve Dower wrote:
>
> On 10Apr2019 1917, Nathaniel Smith wrote:
> > It sounds like --with-pydebug has accumulated a big grab bag of
> > unrelated features, mostly stuff that was useful at some point for
> > some CPython dev trying to de
On Fri, Apr 12, 2019 at 5:05 PM Steve Dower wrote:
>
> On 12Apr.2019 1643, Nathaniel Smith wrote:
> > On Thu, Apr 11, 2019 at 8:26 AM Steve Dower wrote:
> >>
> >> On 10Apr2019 1917, Nathaniel Smith wrote:
> > I don't know how many people use Py_TRACE
On Mon, Apr 15, 2019, 15:27 Michael Sullivan wrote:
> > The main question is if anyone ever used Py_TRACE_REFS? Does someone
> > use sys.getobjects() or PYTHONDUMPREFS environment variable?
>
> I used sys.getobjects() today to track down a memory leak in the
> mypyc-compiled version of mypy.
>
>
lsoruntime.final
class MyClass:
...
This seems kinda awkward. Have you considered giving it a runtime
effect, or providing some way for users to combine these two things
together on their own?
-n
[1] https://github.com/willingc/pep-communication/issu
On Mon, Apr 15, 2019 at 8:58 PM Michael Sullivan wrote:
>
> On Mon, Apr 15, 2019 at 4:06 PM Nathaniel Smith wrote:
>>
>> On Mon, Apr 15, 2019, 15:27 Michael Sullivan wrote:
>>>
>>> > The main question is if anyone ever used Py_TRACE_REFS? Doe
e they came from. I'm not sure if this is
intentional or because they're cutting corners, but it works...
-n
--
Nathaniel J. Smith -- https://vorpus.org
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listi
On Tue, Apr 23, 2019, 05:09 Andrew Svetlov wrote:
> I agree that `from typing import TYPE_CHECKING` is not desirable from
> the import time reduction perspective.
>
> From my understanding code completion *can* be based on type hinting
> to avoid actual code execution.
> That's why I've mentioned
You don't necessarily need rpath actually. The Linux loader has a
bug/feature where once it has successfully loaded a library with a given
soname, then any future requests for that soname within the same process
will automatically return that same library, regardless of rpath settings
etc. So as lo
On Sat, Apr 27, 2019, 04:27 Armin Rigo wrote:
> Hi Neil,
>
> On Wed, 24 Apr 2019 at 21:17, Neil Schemenauer
> wrote:
> > Regarding the Py_TRACE_REFS fields, I think we can't do them without
> > breaking the ABI because of the following. For GC objects, they are
> > always allocated by _PyObject
rate
existing code to the stable ABI.
-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/mailman/options/python-dev/archive%40mail-archive.com
I don't care about the deprecation either way. But can we fix the
individual decorators so both orders work? Even if it requires a special
case in the code, it seems worthwhile to remove a subtle user-visible
footgun.
On Wed, May 15, 2019, 12:39 Ethan Furman wrote:
> In issue 11610* abstractclas
hese exceptions into a file (the output on the Python test suite
> is interesting!). It also becomes trivial to reimplement Thomas's idea
> (kill the process):
What happens if the hook raises an exception?
-n
--
Nathaniel J. Smith -- https://vorpus.org
_
On Thu, May 16, 2019, 09:07 Steve Dower wrote:
>
> Actually, if the default implementation prints the exception message,
> how is this different from sys.excepthook? Specifically, from the point
> of customizing the hooks.
>
sys.excepthook means the program has fully unwound and is about to exit
exception that triggered it?
A clever hook might want the actual object, so it can pretty-print it,
or open an interactive debugger and let it you examine it, or
something. Morally this is similar to calling repr(obj), but it
doesn't literally call repr(obj).
-n
--
Nat
PyPI even if
the stdlib version were public, since the PyPI version can be updated
independently of the host Python.
-n
--
Nathaniel J. Smith -- https://vorpus.org
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/li
aisable() cannot avoid having 3 variables
> (exc_type, exc_value, exc_tb), since they are not consistent as you
> may expect.
I'm actually fine with it having three arguments -- even if it's
technically unnecessary, it's currently 100% consistent across these
low-level APIs,
rs between different coordinate systems. I don't see how that could
> be done via Pillow (which AFAICT only converts complete images).
> RGB<->HSV<->HLS conversion seems to be not available (or not obvious) in
> colorspacious.
Correct, colorspacious doesn't support HSV o
r quickstart example at the top of their README). Same with
flask, django, and probably a bunch of other frameworks. It's *very*
widely used.
-n
--
Nathaniel J. Smith -- https://vorpus.org
___
Python-Dev mailing list
Python-Dev@python.org
https://mail
notice in the docs saying
that it's unmaintained and any use is at your own risk. It's not a
pleasant thing to do, but if that's the reality of the situation then
it's probably better to be up front about it than to stick our fingers
in our ears and waste folks time with spurious te
On Wed, May 22, 2019, 12:14 Sean Wallitsch
wrote:
> Dear python-dev,
>
> I'm writing to provide some feedback on PEP-594, primarily the proposed
> deprecation and reason for the removal of the aifc and audioop libraries.
>
> The post production film industry continues to make heavy use of AIFFs,
On Wed, May 22, 2019, 04:32 Christian Heimes wrote:
> On 22/05/2019 12.19, Steven D'Aprano wrote:
> > I don't think this PEP should become a document about "Why you should
> > use PAM". I appreciate that from your perspective as a Red Hat security
> > guy, you want everyone to use best practices
On Fri, May 24, 2019, 08:08 Ben Cail wrote:
>
> Why not have the PSF hire someone (or multiple people) to be paid to
> work on the maintenance burden? This could be similar to the Django
> fellows:
> https://www.djangoproject.com/fundraising/#who-is-the-django-fellow. It
> seems like a good thing
ourse to discuss some "what if" scenarios
here, in the hopes it will help us make more informed decisions:
https://discuss.python.org/t/1738
-n
--
Nathaniel J. Smith -- https://vorpus.org
___
Python-Dev mailing list
Python-Dev@python.org
On Sat, May 25, 2019, 07:38 Guido van Rossum wrote:
> This looks great.
>
> I only have two nits with the text.
>
> First, why is the snapshot called a "dynamic snapshot"? What exactly is
> dynamic about it?
>
It's dynamic in that it can spontaneously change when certain other events
happen. For
nd so far seem pretty minor, on par
with what we do in every point release. (In fact, in 3/4 of the cases
I looked at, [snapshot] is actually what users seemed to trying to use
in the first place.)
For [proxy] versus [snapshot], a lot depends on what we think of
changing the semantics of exe
On Mon, May 27, 2019 at 9:16 AM Guido van Rossum wrote:
>
> I re-ran your examples and found that some of them fail.
>
> On Mon, May 27, 2019 at 8:17 AM Nathaniel Smith wrote:
[...]
>> The interaction between f_locals and and locals() is also subtle:
>>
>> def f(
oxy] adds "justified" action-at-a-distance, and removes "spooky"
action at a distance.
[snapshot] gets rid of both kinds of action-at-a-distance (at least in
function scope).
-n
--
Nathaniel J. Smith -- https://vorpus.org
___
Python
lobal it does
a direct lookup in the globals object, so it's important that we do
this lookup as fast as possible, and forcing the globals object to be
a actual dict allows some optimizations. For locals, though, we
usually use the "fast locals" mechanism and the mapping object is
most
On Tue, May 28, 2019 at 6:48 PM Greg Ewing wrote:
>
> Nathaniel Smith wrote:
> > - [proxy]: Simply return the .f_locals object, so in all contexts
> > locals() returns a live mutable view of the actual environment:
> >
> > def locals():
> > return get_
n we covered our sin with
new patches, until Simplicity was obscured.
(The current design does makes sense, but you really have to look at
it as a hard-fought compromise between the elegant original design
versus ~30 years of real-world demands. And hey, it could be worse –
look at the fun Intel&#
ace for b1, and tidying up the documentation and comments for b2.
>
> Cheers,
> Nick.
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> htt
to do that anyway,
and having it formally written down might reassure people. It might
also encourage more people to actually try out the prototypes if we
make it very clear that they're going to be asked for feedback.
-n
--
Nathaniel J. Smith -- https://vorpus.org
___
quires a proper deprecation
> period, and that hasn't happened.
> Maybe .pyc files need to be extended to store a list of syntax-related
> DeprecationWarnings and SyntaxWarnings, that are re-issued every time the
> .pyc is loaded? Then we'd at least have the technical capab
On Fri, Aug 9, 2019 at 12:07 PM wrote:
>
> Eric V. Smith wrote:
> > Hopefully the warnings in 3.9 would be more visible that what we saw in
> > 3.7, so that library authors can take notice and do something about it
> > before 3.10 rolls around.
> > Eric
>
> A
fixable using "symbol visibility" features, and it would be
nice to have the option to share stuff between our own C files without
also sharing it with the world, for lots of reasons. But it might be
necessary to implement that first before doing anything to share
_Py_IDENTIFIERs.
-n
erently across different platforms, and so far no-one's done the
work to sort out the details.
-n
--
Nathaniel J. Smith -- https://vorpus.org
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@py
On Mon, Sep 23, 2019, 08:28 Vinay Sajip via Python-Dev <
python-dev@python.org> wrote:
> > requires some newer tools like -fvisibility=hidden that work
> > differently across different platforms, and so far no-one's done the
> > work to sort out the details.
>
> I've started looking at this, but q
hat could easily get bogged down
in complex judgement calls. So let's worry about them separately. Even
if there are too many symbols marked PyAPI_*, we can still get started
on hiding all the symbols that we *know* should be hidden.
-n
--
Nathanie
tml : my notes on moving
> globals to per interpreter states
> * https://bugs.python.org/issue36710
> * https://bugs.python.org/issue38644
>
> Victor
> --
> Night gathers, and now my watch begins. It shall not end until my death.
> ___
> Python-Dev
On Sun, Nov 17, 2019 at 1:58 PM Nick Coghlan wrote:
> On Sat., 16 Nov. 2019, 8:26 am Nathaniel Smith, wrote:
>>
>> As you know, I'm skeptical that PEP 554 will produce benefits that are
>> worth the effort, but let's assume for the moment that it is, and
>> w
o the ast.py module or a new one if people
> feel strongly about it.
How does it compare to Berker's popular and well-maintained PyPI
package for this? https://github.com/berkerpeksag/astor
-n
--
Nathaniel J. Smith -- https://vorpus.org
___
P
(Replying here since b.p.o doesn't seem to want to let me log in)
I've used the PEP 523 API several times for multiple projects, from
analyzing bytecode frequency (which probably could be done with other
means) to inspecting type information from function calls. I could probably
do such analysis a
fcount; /* Limited memory or saturating */
> }
>
> This format would reduce the size of a Python object without slots, on a
> 64 bit machine, from 40 to 16 bytes.
In this example, I can't figure out how you'd map your 26 bit class_id
to a class object. On a 32-bit sy
many sockets you can have open. When I wrote
a simple process that opens as many sockets as it can in a loop, I
didn't get any error; eventually the machine just locked up. (I guess
this is another example of why it can be better to have explicit
limits!)
-n
--
Nathaniel J. Smith
compacted
object header bit, which makes it a magnet for critique. Also, I don't
understand how this idea would work at all :-). So I'd either remove
it or else make it more detailed, one or the other.
-n
--
Nathaniel J. Smith -- https://vorpus.org
While working on the implementation with Guido I made a list of things that
inherit from typing.Generic in typeshed that haven't been
listed/implemented yet.
https://github.com/gvanrossum/cpython/pull/1#issuecomment-582781121
On Sat, Feb 22, 2020, 3:50 PM Nick Coghlan wrote:
> This looks like
The discussion on the name change came from Łukasz
https://github.com/python/cpython/pull/18239#discussion_r380996908
I suggested "GenericType" to be in line with other things in types.py.
On Mon, Feb 24, 2020 at 8:39 PM Guido van Rossum wrote:
> I can't find it right now, but IIRC somebody com
t;suffix", to reduce the jargon factor and for consistency with
startswith/endswith.
-n
--
Nathaniel J. Smith -- https://vorpus.org
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@pytho
read_kill, and then let the main thread set its own eval_breaker
etc.
-n
--
Nathaniel J. Smith -- https://vorpus.org
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailma
On Sat, Mar 21, 2020 at 11:35 AM Steven D'Aprano wrote:
>
> On Fri, Mar 20, 2020 at 06:18:20PM -0700, Nathaniel Smith wrote:
> > On Fri, Mar 20, 2020 at 11:54 AM Dennis Sweeney
> > wrote:
> > > This is a proposal to add two new methods, ``cutprefix`` and
>
d confirm that they match?
-n
--
Nathaniel J. Smith -- https://vorpus.org
___
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.o
(Trusty assistant reporting in) I should also note that further up the
output there is a FileNotFoundError for sqlite3.dll, perhaps it isn't built
or is in the wrong place?
Ethan
On Mon, Apr 6, 2020, 7:19 PM Guido van Rossum wrote:
> I have a large PR (https://github.com/python/cpython/pull/18
'glom(json_obj, "a.b.c", default=None)'.
Like anything there are probably trade-offs and situations where
something like AttributeDict is better, but figured I'd throw that out
there as another option to consider.
-n
--
Nathaniel J. Smith -- https://vorpus.org
an obj["a"]["b.c"][2],
but OTOH you get better error message on failed lookups,
null-coalescing support by using default=, etc.
-n
--
Nathaniel J. Smith -- https://vorpus.org
___
Python-Dev mailing list -- python-dev@python.org
701 - 800 of 1711 matches
Mail list logo
