On 16 June 2016 at 12:34, Donald Stufft wrote:
> [1] I don’t think using os.urandom is incorrect to use for security sensitive
> applications and I think it’s a losing battle for Python to try and fight
> the rest of the world that urandom is not the right answer here.
>
> [2] python-dev t
On 16 June 2016 at 16:58, Nathaniel Smith wrote:
> The word "cryptographic" here is a bit of a red herring. The guarantee that
> a CSPRNG makes is that the output should be *unguessable by third parties*.
> There are plenty of times when this is what you need even when you aren't
> using actual cr
On 16 June 2016 at 18:03, Nick Coghlan wrote:
> On 16 June 2016 at 09:39, Paul Moore wrote:
>> I'm willing to accept the view of the security experts that there's a
>> problem here. But without a clear explanation of the problem, how can
>> a non-specialist like
On 3 July 2016 at 21:22, Brett Cannon wrote:
> Topic 2
> ===
> Independent releases of the stdlib could be done, although if we break the
> stdlib up into individual repos then it shifts the conversation as
> individual modules could simply do their own releases independent of the big
> stdlib
On 3 July 2016 at 22:04, Brett Cannon wrote:
> This last bit is what I would advocate if we broke the stdlib out unless an
> emergency patch release is warranted for a specific module (e.g. like
> asyncio that started this discussion). Obviously backporting is its own
> thing.
It's also worth not
On 5 July 2016 at 18:02, Steven D'Aprano wrote:
> Yes, we're all probably sick and tired of hearing all the Chicken Little
> scare stories about how the GIL is killing Python, how everyone is
> abandoning Python for Ruby/Javascript/Go/Swift, how Python 3 is killing
> Python, etc. But sometimes the
On 5 July 2016 at 19:01, Petr Viktorin wrote:
> There are people who want to cut out what they don't need – to build
> self-contained applications (pyinstaller, Python for Android), or to
> eliminate unnecessary dependencies (python3-tkinter). And they will do
> it with CPython's blessing or witho
On 6 July 2016 at 10:01, Petr Viktorin wrote:
> 4) Adjust pip to ignore installed stdlib modules that are present, so
> distributions can depend on "statistics" and not "statistics if
> python_ver<3.4". (statistics is just an example, obviously this would
> only work for modules added after the PE
On 6 July 2016 at 14:55, Steve Dower wrote:
> I think the wsgiref issue was that it wasn't in site-packages and so
> couldn't be removed or upgraded. Having the dist-info available and putting
> them in site-packages (or a new directory?) lets us handle
> querying/replacing/removing using the exis
On 11 July 2016 at 10:51, Lele Gaifax wrote:
> as I'm going to have a need to use the native `online backup API`__ provided
> by SQLite, I looked around for existing solutions and found `sqlitebck`__.
>
> I somewhat dislike the approach taken by that 3rd party module, and I wonder
> if the API sho
On 11 July 2016 at 14:11, Steven D'Aprano wrote:
> But generalising this to all possibly mismatches between a C class
> implementation and a Python function implementation doesn't necessarily
> follow. Raymond's general point about simplicity versus feature creep
> still stands, even if in this ca
On 11 July 2016 at 16:59, Lele Gaifax wrote:
> Paul Moore writes:
>
>> There's also apsw (https://github.com/rogerbinns/apsw), which appears
>> to support backup - http://rogerbinns.github.io/apsw/backup.html.
>
> Thank you, will have a look: not sure it fits my
On 12 July 2016 at 06:21, Nick Coghlan wrote:
> Based on this discussion, I've come to the conclusion that there are
> only two cases where I'd like PEP 399 to document pre-emptive answers
> to "What counts as sufficiently compatible?" question
This sounds reasonable to me (particularly as it say
t I
>> once knew about the Windows registry...
>
>
> He might not be pleased at the nomination, but Paul Moore would be my first
> choice.
:-) Thanks for the vote of confidence, Steve - if Guido's OK with it
I'd be willing to do this.
Paul
On 15 July 2016 at 23:20, Steve Dower wrote:
> Hi all
>
> I'd like to get this PEP approved (status changed to Active, IIUC).
Some comments below.
> So far (to my knowledge), Anaconda is writing out the new metadata and
> Visual Studio is reading it. Any changes to the schema now will require
>
On 16 July 2016 at 18:59, Guido van Rossum wrote:
> Yup! Paul is now officially the BDFL-delegate for PEP 514.
OK. I've just been reviewing the PEP and have posted some comments.
There's a lot of words(!), but I don't think there's a huge amount of
substantive change, mostly it's just confirmatio
On 18 July 2016 at 17:33, Steve Dower wrote:
>> Some comments below.
>
> Awesome, thanks! Posted a pull request at
> https://github.com/python/peps/pull/59 for ease of diff reading, and some
> commentary below (with aggressive snipping).
Thanks - I'll do a proper review of that, but just wanted t
On 18 July 2016 at 18:01, Paul Moore wrote:
> On 18 July 2016 at 17:33, Steve Dower wrote:
>>> Some comments below.
>>
>> Awesome, thanks! Posted a pull request at
>> https://github.com/python/peps/pull/59 for ease of diff reading, and some
>> commen
On 19 July 2016 at 10:49, Paul Moore wrote:
> On 18 July 2016 at 18:01, Paul Moore wrote:
>> On 18 July 2016 at 17:33, Steve Dower wrote:
>>>> Some comments below.
>>>
>>> Awesome, thanks! Posted a pull request at
>>> https://github.com/python
This PEP is now accepted. Congratulations, Steve! And thanks for
putting up with all of my last-minute questions :-)
Paul
On 23 July 2016 at 21:20, Guido van Rossum wrote:
> I'll let Paul pronounce. But you should probably have a BDFL-Delegate:
> ... header.
>
> On Sat, Jul 23, 2016 at 12:16 PM,
On 28 July 2016 at 17:51, Barry Scott wrote:
> Why do you need SysArchitecture? Surely the 32bit pythons are registered in
> the 32bit registry and the 64 bit pythons in the 64 bit registry.
Per-user installs go in HKEY_CURRENT_USER, which is not
architecture-specific. So you either need SysArch
On 31 August 2016 at 00:55, Gregory P. Smith wrote:
> I find that users of such systems either use only what their distro itself
> supplies (ie: ancient versions at that point) or are fully comfortable
> building any dependencies their own software needs. If they are comfortable
> building a CPyth
On 1 September 2016 at 23:31, Steve Dower wrote:
[...]
> As a result, POSIX-focused library authors prefer to use bytes to represent
> paths.
A minor point, but in my experience, a lot of POSIX-focused authors
are happy to move to a better text/bytes separation, so I'd soften
this to "some POSIX-
On 2 September 2016 at 03:35, Steve Dower wrote:
> I'd need to test to be sure, but writing an incomplete code point should
> just truncate to before that point. It may currently raise OSError if that
> truncated to zero length, as I believe that's not currently distinguished
> from an error. What
On 5 September 2016 at 06:54, Steve Dower wrote:
> +Using the raw object with small buffers
> +---
> +
> +Code that uses the raw IO object and attempts to read less than four
> characters
> +will now receive an error. Because it's possible that any single chara
On 5 September 2016 at 10:37, Martin Panter wrote:
> On 5 September 2016 at 09:10, Paul Moore wrote:
>> On 5 September 2016 at 06:54, Steve Dower wrote:
>>> +Using the raw object with small buffers
>>> +---
>>> +
>&
On 5 September 2016 at 14:36, Steve Dower wrote:
> The best fix is to use a buffered reader, which will read all the available
> bytes and then let you .read(1), even if it happens to be an incomplete
> character.
But this is sys.stdin.buffer.raw, we're talking about. People can't
really layer an
On 5 September 2016 at 18:38, Steve Dower wrote:
>> Can you provide an example of how I'd rewrite the code that I quoted
>> previously to follow this advice? Note - this is not theoretical, I
>> expect to have to provide a PR to fix exactly this code should this
>> change go in. At the moment I ca
On 5 September 2016 at 20:30, Steve Dower wrote:
> The only case we can reasonably handle at the raw layer is "n / 4" is zero
> but n != 0, in which case we can read and cache up to 4 bytes (one wchar_t)
> and then return those in future calls. If we try to cache any more than that
> we're substit
On 5 September 2016 at 20:34, eryk sun wrote:
> Paul, do you have example code that uses the 'raw' stream? Using the
> buffer should behave as it always has -- at least in this regard.
> sys.stdin.buffer requests a large block, such as 8 KB. But since the
> console defaults to a cooked mode (i.e.
On 5 September 2016 at 21:19, Paul Moore wrote:
>
> The code I'm looking at doesn't use the raw stream (I think). The
> problem I had (and the reason I was concerned) is that the code does
> some rather messy things, and without tracing back through the full
> code path
On 14 September 2016 at 11:32, Serhiy Storchaka wrote:
> On 13.09.16 02:35, Ned Deily wrote:
>>
>> On behalf of the Python development community and the Python 3.6 release
>> team, I'm happy to announce the availability of Python 3.6.0b1. 3.6.0b1
>> is the first of four planned beta releases of Py
On 14 September 2016 at 13:18, Franklin? Lee
wrote:
> On Sep 9, 2016 1:35 AM, "Benjamin Peterson" wrote:
>> On Thu, Sep 8, 2016, at 22:33, Tim Delaney wrote:
>> > Are sets also ordered by default now? None of the PEPs appear to mention
>> > it.
>>
>> No.
>
> Is there anyone working to move sets i
On 15 September 2016 at 07:31, Serhiy Storchaka wrote:
> Note that this is made at the expense of the 20% slowing down an iteration.
>
> $ ./python -m timeit -s "d = dict.fromkeys(range(10**6))" -- "list(d)"
> Python 3.5: 66.1 msec per loop
> Python 3.6: 82.5 msec per loop
On my Windows 7 PC with
On 15 September 2016 at 09:57, Victor Stinner wrote:
> 2016-09-15 10:02 GMT+02:00 INADA Naoki :
>> In my environ:
>>
>> ~/local/python-master/bin/python3 -m timeit -s "d =
>> dict.fromkeys(range(10**6))" 'list(d)'
>
> Stop! Please stop using timeit, it's lying!
>
> * You must not use the minim
On 15 September 2016 at 10:43, Raymond Hettinger
wrote:
> Something like this will reveal the true and massive improvement in iteration
> speed:
>
> $ ./python.exe -m timeit -s "d=dict.fromkeys(map(str,range(10**6)))"
> "list(d)"
>py -3.5 -m timeit -s "d=dict.fromkeys(map(str,range(10**6))
On 10 October 2016 at 14:34, Giampaolo Rodola' wrote:
> This is what I've bumped into just now:
>
> python setup.py upload_sphinx --upload-dir=docs/_build/html
> running upload_sphinx
> Submitting documentation to https://upload.pypi.org/legacy/
> Upload failed (410): Uploading documentation is no
On 10 October 2016 at 17:49, MRAB wrote:
> If you lookup something in a dict, it'll be a borrowed reference.
>
> If the dict is globals() and there's no GIL, another thread could delete the
> item while your code had the borrowed reference.
>
> It looks like there might be a lot that will need to
On 10 October 2016 at 18:50, Nathaniel Smith wrote:
> I assume Larry is way ahead of us on this,
Yeah, I'd imagine you're right on that :-)
Paul
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubs
On 11 October 2016 at 03:15, Elliot Gorokhovsky
wrote:
> There's an option to provide setup code, of course, but I need to set up
> before each trial, not just before the loop.
Typically, I would just run the benchmark separately for each case,
and then you'd do
# Case 1
python -m perf timeit -s
On 11 October 2016 at 14:04, Elliot Gorokhovsky
wrote:
> Right, that sounds good, but there's just one thing I don't understand
> that's keeping me from using it. Namely, I would define a benchmark list L
> in my setup, and then I would have code="F=FastList(L);F.fastsort()". The
> problem here is
On 11 October 2016 at 15:00, Chris Angelico wrote:
> On Wed, Oct 12, 2016 at 12:51 AM, Paul Moore wrote:
>> On 11 October 2016 at 14:04, Elliot Gorokhovsky
>> wrote:
>>> Right, that sounds good, but there's just one thing I don't understand
>>> that&
On 11 October 2016 at 15:32, Elliot Gorokhovsky
wrote:
> But the sort mutates F...does the setup get executed each time? I thought
> it's just at the beginning. So then F gets mutated (sorted) and subsequent
> sorts time wrong.
Did I not say earlier - sorry. I'm suggesting that you put each timin
On 20 October 2016 at 17:38, Ethan Furman wrote:
> On 10/20/2016 03:56 AM, Victor Stinner wrote:
>
>> Last months, I worked a lot on benchmarks. I ran benchmarks, analyzed
>> results in depth (up to the hardware and kernel drivers!), I wrote new
>> tools and enhanced existing tools.
>
>
> Thank yo
On 4 November 2016 at 08:36, Simon Cross wrote:
> On Fri, Nov 4, 2016 at 9:56 AM, Eric V. Smith wrote:
>> 2. The parser sees that it's an f-string, and breaks it into expression and
>> text parts.
>
> I'm with Fabio here. It would be really nice to have a grammar
> specified and documented for th
On 9 November 2016 at 16:20, Fabio Zadrozny wrote:
> Also, as a feedback, I found it a bit odd that there can't be any space nor
> new line between the last format specifiers and '}'
FWIW, that is the case for normal format strings, as well:
>>> print("{!r\n}".format(12))
Traceback (most recent
On 10 December 2016 at 10:15, Terry Reedy wrote:
> On 12/10/2016 4:05 AM, David Mertz wrote:
>>
>> I'm forwarding this to the PSF Trademarks committee. If there is a
>> violation, it's a misuse of trademark, not copyright on the code which
>> has the Python license stack.
>
>
> I believe that this
On 10 December 2016 at 10:36, Paul Moore wrote:
> Someone has raised an issue against the project at
> https://github.com/naftaliharris/python2.8/issues/47 We should
> probably see what the project owner's response to that is.
By the way, looking at the project history, it seem
On 13 December 2016 at 13:47, KH Luke Kim wrote:
> Yeah, but is it supposed to be avoided to apply new features in Python 3.x
> to Python 2.x? Sorry if there's already a consensus.
Yes. Only security-related new features will ever be backported to
Python 2 (and even those will be subject to discu
On 14 December 2016 at 05:10, Sesha Narayanan Subbiah
wrote:
> From http://legacy.python.org/download/, I could see that the current
> production releases are Python 3.4 and Python 2.7.6.
That URL seems to be out of date. You should refer to www.python.org,
specifically https://www.python.org/dow
On 9 January 2017 at 11:42, Steve Holden wrote:
> One of my developers recently submitted a pull request incuding a number of
> lines like
>
> import os as _os
>
> When I asked him why he suggested a) this would improve encapsulation, and
> b) the practice was supported in the stdlib. Further inve
On 17 January 2017 at 20:02, Steve Dower wrote:
> Avoiding header files would be my only request. As Brett says, the C99
> requirement should not be enforced on all embedders or extenders, so we
> should try and keep the headers they'll use as compatible as possible.
Agreed, we probably shouldn't
On 29 January 2017 at 20:30, Steve Holden wrote:
> Why not declare re deprecated and remove it in Python 4? I am pretty sure
> everyone wants to keep re in all 3.x releases, but that support need not
> extend beyond. So Py4 would have no battery for re, but it would (should!)
> be common knowledge
On 31 January 2017 at 09:19, Cory Benfield wrote:
>
> In general, it is unwise to mix trust stores. If you want to use your OS’s
> trust store, the best approach is to use the OS’s TLS stack as well. At
> least that way when a user says “It works in my browser”, you know it should
> work for you t
On 31 January 2017 at 14:54, Cory Benfield wrote:
>
> So C# applications are Windows-native safe on Windows, and are a crapshoot
> elsewhere. For Java vs Python, I’d say we’re slightly ahead right now.
That's precisely the sort of answer I was after. Many thanks. The
additional detail is interes
On 1 March 2017 at 15:34, Yury Selivanov wrote:
> +1 to put both in contextlib.
With the proviso that the implementation shouldn't depend on asyncio.
As Yury says, it should be framework agnostic, let's be careful to
make that the case and not rely on helpers from asyncio, either
deliberately or
On 23 March 2017 at 20:41, Ned Batchelder wrote:
>>> If unittests searches normal directly, it may walk deep into very
>>> large tree containing
>>> millions of directories. I don't like it.
>
>> That is a risk, OTOH I think the failure to do what folk expect is a
>> bigger risk.
>
> The issue he
On 28 March 2017 at 12:24, Miro Hrončok wrote:
> I'd like some clarification on what ABI compatibility we can expect.
> * Should the ABI be stable across patch releases (so calling
> PySlice_AdjustIndices from an existing macro would be a bug)?
> * Should the ABI be forward-compatible within a m
On 28 March 2017 at 18:05, Glenn Linderman wrote:
> Somewhere I got the idea that extension authors were supposed to build
> against the n.m.0 releases, expressly so that the extensions would then be
> compatible with the whole n.m.x series of releases. Did I dream that?
I've certainly never hear
On 28 March 2017 at 17:31, Nathaniel Smith wrote:
> IMO this is a bug, and depending on how many packages are affected it might
> even call for an emergency 3.6.2. The worst case is that we start getting
> large numbers of packages uploaded to pypi that claim to be 3.6.0 compatible
> but that cras
This is correct behaviour. I would suggest that you post this to
python-list for a full discussion of what's going on here, but
basically the default value for argument bar of __init__ is created at
class creation time, and then reused for every instance. This is a
common mistake made by newcomers,
On 11 May 2017 at 01:50, Steven D'Aprano wrote:
> On Tue, May 09, 2017 at 10:05:43AM -0700, Ethan Furman wrote:
>
>> A comment on a recent SO answer [1] wondered why my aenum library wasn't
>> mentioned in the docs to help guide people that needed/wanted more advanced
>> Enum options to it.
>
> I
On 22 May 2017 at 19:17, Steve Dower wrote:
> One of the main reasons we are stuck with an old libffi fork in CPython is
> because the newer versions do not support protection from calling functions
> with too few/many arguments:
>
> https://docs.python.org/3/library/ctypes.html?highlight=ctypes#c
On 31 May 2017 at 15:11, Victor Stinner wrote:
> So I would suggest to modify the PEP 7 to *always* require braces for if.
>
> I would also suggest to require braces on "for(...) { ... }" and
> "while(...) { ... }". But only if the code has to be modified, not
> only to update the coding style.
>
On 1 June 2017 at 17:14, Chris Angelico wrote:
> Python 2 users include people on Windows who install it themselves,
> and then have no mechanism for automatic updates. They'll probably
> stay on whatever 2.7.x they first got, until something forces them to
> update. But it also includes people on
On 8 June 2017 at 17:40, Steve Dower wrote:
> I'm just going to straight up admit that I've lost track of the point of
> this thread.
You have my sympathies - I'm not really following it either :-(
> It sounds like we don't *need* to backport any of ssl into the Python 2.7
> standard library, as
On 12 June 2017 at 21:11, Terry Reedy wrote:
> I do not see this with my fresh 3.7 repository debug build on my Win 10
> machine. If I did, I would be -1000. This warning should be treated
> as a deprecation warning, off by default.
My understanding is that this is a Unix-only change. If it aff
On 25 June 2017 at 18:31, Donald Stufft wrote:
>
> I have used it. I don’t use it every day but I’ve never had it fail on me
> unless the contributor has unchecked the flag. I just ``git remote add
> `` then checkout their branch, add more
> commits, and push to their branch.
That's relatively s
On 14 July 2017 at 14:33, Victor Stinner wrote:
>> A lot of great optimizations and bugfixes. Speaking of optimizations, I just
>> wrote some code which takes 12s on Python 2.7 and 5s on Python 3.5. so we're
>> doing something right! I might post about it shortly.
>
> Hum, I'm curious to see which
On 20 July 2017 at 18:53, Jim J. Jewett wrote:
> Is it too hard to create a daemon server?
> Is the communication and context switch slower than a new startup?
> Is the pattern just not well-enough advertised?
Managing a daemon (including things like stopping it when it's been
idle for "too long"
On 21 July 2017 at 23:53, David Mertz wrote:
> I would guess that Windows users don't tend to run lots of command line
> tools where startup time dominates, as *nix users do.
Well, in the sense that many Windows users don't use the command line
at all, this is true. However, startup time is a def
On 8 August 2017 at 17:21, Steve Dower wrote:
> For a while I've been uploading the official releases to nuget.org. These
> packages can be installed with nuget.exe (latest version always available at
> https://aka.ms/nugetclidl), which is quickly becoming a standard tool in
> Microsoft's build to
On 24 August 2017 at 15:38, Barry Warsaw wrote:
> Yes, but in conversations about Python, the term “context” (in the context of
> context managers) comes up way more often than the term “scope”. I actually
> think Python’s scoping rules are fairly easy to grasp, as there aren’t that
> many lev
On 30 August 2017 at 10:48, Nick Coghlan wrote:
> On 30 August 2017 at 19:39, Antoine Pitrou wrote:
>> On Wed, 30 Aug 2017 08:48:56 +0300
>> Serhiy Storchaka wrote:
>>> Please, please don't forget to edit commit messages before merging. An
>>> excessively verbose commit message will be kept in t
On 31 August 2017 at 20:27, Brett Cannon wrote:
> So you would want a comment when the PR reaches "awaiting merge" with
> instructions requesting the author do their own squash commit to simplify
> the message for us?
That would work. It could say that the PR consists of multiple commits
and the
On 6 September 2017 at 11:09, Antoine Pitrou wrote:
> On Wed, 6 Sep 2017 11:26:52 +0900
> INADA Naoki wrote:
>>
>> Like that, should we say "atomic & threadsafe __setitem__ for simple
>> key is implementation detail of CPython and PyPy. We recommend
>> using mutex when using OrderedDict from mul
On Mon, 18 Oct 2021 at 19:29, Guido van Rossum wrote:
> where the convention is that keys at any level may be omitted altogether and
> config itself may be NOne, then to safely access the value of
> config["handler"]["parameters"]["y"] we would have to write
>
> y = None # Default
> if config
On Tue, 19 Oct 2021 at 00:55, Guido van Rossum wrote:
>
> I should have added that I also don't feel I want to go at bat to fight for
> this PEP. I do observe that it looks like the folks used to building large
> systems (in Python or other languages) don't seem to like it, while it seems
> to
On Wed, 3 Nov 2021 at 10:11, Marc-Andre Lemburg wrote:
> I don't think limiting the source code encoding is the right approach
> to making code more secure. Instead, tooling has to be used to detect
> potentially malicious code points in code.
+1
Discussing "making code more secure" without bein
I've had about 5 or 6 of them.
Paul
On Thu, 4 Nov 2021 at 19:22, Brett Cannon wrote:
>
> What notification? (I fully admit I may not have gotten one due to some team
> I'm in, but I have no such notification if it happened recently.)
>
> On Thu, Nov 4, 2021 at 12:16 AM Larry Hastings wrote:
>>
On Tue, 9 Nov 2021 at 06:31, Ethan Furman wrote:
(IMO, Steven D'Aprano's comment above, which I don't think you have
responded to yet, is the clearest summary of the options here. I agree
with what he says, but just wanted to clarify one point below).
> I've had a couple people tell me that they
On Tue, 9 Nov 2021 at 10:39, Sebastian Rittau wrote:
> This might be better API design (although I don't think Python should be
> opinionated about this outside the standard library), but this still
> leaves the API change example and the very real problem of @overloads
> unsolved.
You can handl
On Thu, 11 Nov 2021 at 11:51, Antoine Pitrou wrote:
>
> On Wed, 10 Nov 2021 21:12:17 -0600
> Tim Peters wrote:
> > [Bob Fang ]
> > > This is a modest proposal to consider having sorted containers
> > > (http://www.grantjenks.com/docs/sortedcontainers/) in standard library.
> >
> > +1 from me, but
On Sun, 21 Nov 2021 at 07:50, Christopher Barker wrote:
>
> TL;DR:
>
> Annotations can be, and are, used for other things than "typing". I just
> noticed that PEP 563 apparently deprecated those other uses (well, sort of:
> "uses for annotations incompatible with the aforementioned PEPs should b
On Fri, 26 Nov 2021 at 05:14, Guido van Rossum wrote:
>
> My memory is also hazy, but I'm quite sure that *in my mind* annotations were
> intended as a compromise between conflicting proposals for *typing*. We
> didn't have agreement on the syntax or semantics, but we did know we wanted
> to do
On Thu, 25 Nov 2021 at 21:45, Christopher Barker wrote:
> The issue is that, intended or not, typing is making it's way into Python
> culture. As an instructor of beginning python users, I am unsure at this
> point when to introduce type annotations.
>
> What is their role? Up to today, I have t
On Fri, 26 Nov 2021 at 17:13, Guido van Rossum wrote:
>> Although the more I think about it, given that I believe dataclasses
>> use eval "under the hood", the less I understand *how* it manages to
>> do that without special-case knowledge of the dataclass decorator...)
>
> Static checkers specia
On Tue, 30 Nov 2021 at 02:52, Steve Dower wrote:
>
> THAT'S the kind of thing that also has been happening with typing, and
> why some of us feel the need to publicly re-state things that are all
> agreed upon within this group, but are struggling to be heard over the
> public discourse on the top
On Tue, 30 Nov 2021 at 09:37, Chris Angelico wrote:
>
> On Tue, Nov 30, 2021 at 8:19 PM Paul Moore wrote:
> > Also, related to the question Terry raised, IMO it would be useful to
> > have a clear statement on code that *does* use type annotations, but
> > violate
On Tue, 30 Nov 2021 at 12:39, Oscar Benjamin wrote:
> There are other open "issues" like this for SymPy where the
> presumption is that not having type hints is now to be considered a
> deficiency of the library regardless of whether the hints have any
> benefit for internal use. I don't object t
On Tue, 30 Nov 2021 at 19:07, Brett Cannon wrote:
>
> On Tue, Nov 30, 2021 at 9:09 AM Steven D'Aprano wrote:
>>
>> On Tue, Nov 30, 2021 at 02:30:18PM +, Paul Moore wrote:
>>
>> > And to be clear, it's often very non-obvious how to annotate som
On Wed, 1 Dec 2021 at 12:08, Sebastian Rittau wrote:
> Please note that users of you library usually won't care that the library
> uses type hints. It's more important that there are type hints for the API,
> which can also be supplied using a stub file.
I tried that route, but I was informed
On Fri, 3 Dec 2021 at 00:10, Shantanu Jain wrote:
>
> @Paul
>
> > ... missing resource is a central set of typing documentation that includes
> > examples, FAQs and best practices as well as reference materials
>
> Like Sebastian, I agree, and this is something we're making progress on.
That's g
On Wed, 8 Dec 2021 at 12:42, Petr Viktorin wrote:
> > I assume it would be insensitive to ask whether we could just get rid of
> > the stable ABI altogether and focus on the limited API? Just tell
> > everyone they have to rebuild binary wheels for every Python feature
> > release. Presumably the
I agree. The same concerns and reservations apply for me.
On Sat, 18 Dec 2021 at 21:13, Terry Reedy wrote:
>
> Batuhan expresses my concerns better than I could, so I just add my
> agreement.
>
> On 12/18/2021 3:13 PM, Batuhan Taskaya wrote:
>
> > tl;dr: I find it very troubling that we are going
On Tue, 21 Dec 2021 at 18:35, Steven Troxler wrote:
>
> I've been thinking about readability hard because I share many of your
> concerns about readability.
Before I comment on syntax, I'd like to question the example:
> An example
> =
>
> The function
>
>
> To get at w
To me, these are mostly convincing examples that people need to name
parts of a complex type like this :-)
I don't actually find any of the syntaxes better than any other. They
are all a bit bad, but I view that as the fault of the complex nested
types, not the syntax (hence my preference for nami
On Mon, 10 Jan 2022 at 11:43, Batuhan Taskaya wrote:
>
> > Does someone know if linters like pylint or pylakes current warn on
> > "assert(test, msg)" statements?
>
> I believe so, both the python itself (through SyntaxWarnings) and
> other linters warn about this.
❯ py
Python 3.10.1 (tags/v3.10
On Mon, 10 Jan 2022 at 23:04, Greg Ewing wrote:
>
> Most of the effort of learning to read type expressions, in any
> language, is learning their semantics, which is very different
> from value expressions. Whether they happen to superficially
> resemble other parts of the language is pretty much
On Thu, 13 Jan 2022 at 08:48, Nick Coghlan wrote:
>
> The existing section on runtime behaviour in the PEP doesn't look ready for
> SC consideration, since it essentially says "this hasn't been defined yet".
+1. The runtime behaviour needs to be specified. Otherwise this PEP is
a spec for how ty
801 - 900 of 1862 matches
Mail list logo
