On Thu, Feb 11, 2021 at 8:29 PM Terry Reedy wrote:
> On 2/11/2021 3:23 PM, Michał Górny wrote:
> > Hello,
> >
> > I'm the primary maintainer of CPython packages in Gentoo. I would like
> > to discuss possible improvement to the release process in order to
> > accelerate releasing security fixes
Hi,
First of all, sorry for not commenting on this earlier.
I only became aware of this PEP yesterday.
I like the general idea of adding a marker to show that a boolean
function narrows the type of one (or more?) of its arguments.
However, the suggested approach seems clunky and impairs
Offering encoding="locale" (or open.locale or ... ) instead of a long function
call using False (locale.getpreferredencoding(False)) seems like a win for
Explicit is Better Than Implicit. It would then be possible to say "yeah,
locale really is what I meant".
Err... unless the charset
>From my point of view, the process of standardizing through a formal
standards body is a tedious, verbose, laborious, bureaucratic and
often contentious process.
I'd really like to know quantitatively what the benefits would be of
running that gauntlet, as I'm not sure they would outweigh the
What would it take to create an ANSI, ECMA and/or ISO standard for Python?
It seems to have really helped C.
It looks like Java isn't standardized, and it's done OK, though perhaps it
was healthier in the past - before Oracle decided API's were ownable.
I think standardizing Python might be
On Fri, Feb 12, 2021 at 10:51 AM Paul Bryan wrote:
> From my point of view, the process of standardizing through a formal
> standards body is a tedious, verbose, laborious, bureaucratic and
> often contentious process.
>
I've never participated in such a standardization, but I'm sure it's hard
On Fri, Feb 12, 2021 at 11:02 AM Ivan Pozdeev via Python-Dev <
python-dev@python.org> wrote:
> How a standard by ANSI, ECMA and/or ISO is any better than a standard by
> the PSF?
>
I don't think what the PSF is producing is truly a standard.
> Is PSF bad at "controlling its growth and avoiding
Current PEP 647 draft says:
"Some built-in type guards provide narrowing for both positive and negative
tests (in both the if and else clauses)"
Should there be a separate (sub-?) type for those TypeGuards that *do* allow
narrowing even on a False? Leaving it as an implementation detail
How a standard by ANSI, ECMA and/or ISO is any better than a standard by the
PSF?
Is PSF bad at "controlling its growth and avoiding featuritis" in your opinion
or smth?
On 12.02.2021 21:33, Dan Stromberg wrote:
What would it take to create an ANSI, ECMA and/or ISO standard for Python?
It
What if PSF were to undertake codifying a language specification?
On Fri, 2021-02-12 at 11:57 -0800, Dan Stromberg wrote:
>
> On Fri, Feb 12, 2021 at 11:02 AM Ivan Pozdeev via Python-Dev
> wrote:
> > How a standard by ANSI, ECMA and/or ISO is any better than a
> > standard by the PSF?
> >
>
>
ACTIVITY SUMMARY (2021-02-05 - 2021-02-12)
Python tracker at https://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open7415 (+36)
closed 47529 (+34)
total 54944 (+70)
Open issues
That could be good. :) And sometimes standards are rubber stamped by
other bodies.
On Fri, Feb 12, 2021 at 12:03 PM Paul Bryan wrote:
> What if PSF were to undertake codifying a language specification?
>
> On Fri, 2021-02-12 at 11:57 -0800, Dan Stromberg wrote:
>
>
> On Fri, Feb 12, 2021 at
On 13/02/21 9:03 am, Paul Bryan wrote:
What if PSF were to undertake codifying a language specification?
We have the Language Reference and Library Reference. Do they
not count as specifications?
--
Greg
___
Python-Dev mailing list --
On Fri, Feb 12, 2021 at 2:01 PM Greg Ewing
wrote:
> On 13/02/21 9:03 am, Paul Bryan wrote:
> > What if PSF were to undertake codifying a language specification?
>
> We have the Language Reference and Library Reference. Do they
> not count as specifications?
>
It's been a long time since I looked
>From talking to people who at various times have participated in a language
standardization process, I've learned that it's not a panacea, it's an
enormous amount of work, it doesn't guarantee a good outcome, and plenty of
languages do just fine without it. Also, it costs real money. A lot. I
A call for standardization is typically done when multiple competing
de-facto standards competing for space, especially if it's relatively
immature, as a way to bring stakeholders together and reduce fragmentation.
You don't just go through the standards process for its own sake, unless
it's a
But this message seems to say "Argue with me!"
___
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.org/
Message archived at
On Fri, Feb 12, 2021 at 12:14 PM Jim J. Jewett wrote:
> Current PEP 647 draft says:
>
> "Some built-in type guards provide narrowing for both positive and
> negative tests (in both the if and else clauses)"
>
> Should there be a separate (sub-?) type for those TypeGuards that *do*
> allow
On Sat, Feb 13, 2021 at 4:53 AM Jim J. Jewett wrote:
>
> Offering encoding="locale" (or open.locale or ... ) instead of a long
> function call using False (locale.getpreferredencoding(False)) seems like a
> win for Explicit is Better Than Implicit. It would then be possible to say
> "yeah,
On Sat, Feb 13, 2021 at 6:58 AM Dan Stromberg wrote:
> I believe Python needs to become more independent of CPython, for Python's
> long term health.
>
Since 1997, Python has been defined independently of CPython. There
are numerous documents that define the language semantics for the
benefit
On Fri, Feb 12, 2021 at 2:26 PM Chris Angelico wrote:
> On Sat, Feb 13, 2021 at 6:58 AM Dan Stromberg wrote:
> > I believe Python needs to become more independent of CPython, for
> Python's long term health.
> >
>
> Since 1997, Python has been defined independently of CPython.
Really? It
On Sat, Feb 13, 2021 at 10:42 AM Dan Stromberg wrote:
>
>
> On Fri, Feb 12, 2021 at 2:26 PM Chris Angelico wrote:
>>
>> On Sat, Feb 13, 2021 at 6:58 AM Dan Stromberg wrote:
>> > I believe Python needs to become more independent of CPython, for Python's
>> > long term health.
>> >
>>
>> Since
I definitely think they could. As a developer using Python, they're
fully sufficient for my purposes.
I honestly don't know enough about non-CPython implementations and
their challenges to know what gaps (if any) would need to be filled to
fully implement a compatible version.
On Sat,
On Fri, Feb 12, 2021 at 10:27:01AM +, Mark Shannon wrote:
> It impairs readability, because it muddles the return type.
> The function in the example returns a bool.
> The annotation is also misleading as the annotation is on the return
> type, not on the parameter that is narrowed.
>
> At
My primary reaction seems similar to Mark Shannon's.
When I see this code:
def is_str_list(val: List[object]) -> TypeGuard[List[str]]:
...
I cannot tell what it returns. There is no readable indication in that
this returns a boolean so the reader cannot immediately see how to use the
On Fri, Feb 12, 2021, at 12:33, Dan Stromberg wrote:
>
> What would it take to create an ANSI, ECMA and/or ISO standard for Python?
>
> It seems to have really helped C.
That confuses cause and effect. C was standardized because there sprung up
hundreds of vaguely compatible
In the documentation (not sure whether it should be the documentation
for "open" or for encoding), include at least a link to instructions
on how to (try to) verify that your codebase is using the encoding
parameter properly. Those instructions would say something like "Add
the following lines to
27 matches
Mail list logo
