[Python-Dev] Revive PEP 396 -- Module Version Numbers ?

a "module level dunder" -- but only suggests where it should be put, not how it be used :-) Of course, there will be a need to update the PEP to match current practice, and if it is me doing it, I'd make it very simple So what do you'all think? After thirteen years, it would be n

[Python-Dev] Re: Revive PEP 396 -- Module Version Numbers ?

.0', 'vaex-astro': '0.8.0', 'vaex-jupyter': > '0.6.0', 'vaex-ml': '0.11.1'} > Well, THAT is a great argument for some official standardization! There is sometimes a need for that sort of thing, but I think it's be

[Python-Dev] Re: Revive PEP 396 -- Module Version Numbers ?

de, standardization of versioning specs. -CHB -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython ___ Python-Dev m

[Python-Dev] Re: Revive PEP 396 -- Module Version Numbers ?

#x27;s code anyway. There are no general tools that expect that scheme. And it could be preserved by making a subclass of Version (Or str) that was also a mapping :-) - CHB -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Sof

[Python-Dev] Re: Revive PEP 396 -- Module Version Numbers ?

it right", but I still like things simple :-) Anyway, as the original PEP author is no longer supportive, this is dead in the water unless another core dev is interested in sponsoring this (or a new) PEP. If not, I can stop wasting my and everyone else&

[Python-Dev] Re: Revive PEP 396 -- Module Version Numbers ?

there is something in between the REPL and full on system development -- something simple for quickly scripts is nice too. But a simple standardised version string is fine for that. -CHB -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching -

[Python-Dev] Re: Revive PEP 396 -- Module Version Numbers ?

l. Do we only need to use version information programmatically when we are creating (or installing) packages? I don't think so -- I know I have code that (poorly) does version checking programmatically. -CHB -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scien

[Python-Dev] Re: Revive PEP 396 -- Module Version Numbers ?

On Thu, Apr 15, 2021 at 9:38 AM Barry Warsaw wrote:> From a library maintainers point of view, I personally want to get away> from using __version__ strings at all. They’re kind of a pain to remember> to bump on every new release. That’s a tooling issue, and I don’t think that Python itself

[Python-Dev] Re: Revive PEP 396 -- Module Version Numbers ?

python.org/thread/KBU4EU2JULXSMUZULD5HJJWCGOMN52MK/ ). I believe there is an unfinished PR -CHB -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, num

[Python-Dev] Re: In support of PEP 649

d replacement for type annotations that are accessible as python objects. Absolutely. It is very, very, handy to simply have the object itself easily accessible. -CHB -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and

[Python-Dev] Re: Revive PEP 396 -- Module Version Numbers ?

f what version it is, rather than asking some other part of teh system to go look it up for me. So I could do: import numpy as np print("using np version:", np.__version) And this is pretty consitent with the rest of Python, where many objects (functions, classe

[Python-Dev] Re: In support of PEP 649

in fact, be using annotations for other reasons, but since we haven't been involved in the discussion, some issues may have been missed. -CHB -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development

[Python-Dev] Re: In support of PEP 649

maybe upset, if it looks like changes might be made that may break other features in order to make static typing work better. And as I noted in my last post — many folks have not been paying attention to the typing discussions because they didn’t realize it concerned them. -CHB -- Christopher Barker

[Python-Dev] Re: Relaxing the annotation syntax

ore tightly tied to the original meaning of __getitem__. Nevertheless, it struck me at the time that it would be nice if the Typing use case could be addressed without the complication of making something that made sense in two very different domains. - Chris -- Christopher Barker, PhD (Ch

[Python-Dev] Re: In support of PEP 649

63 changes the (semi-public?) API of dataclasses. Though *maybe* that could be addressed with a dataclasses update -- again, I've only started to think about it -- there was some discussion of that in the BPO, though Eric didn't seem particularly interested. -CHB -- Christopher Barke

[Python-Dev] Re: In support of PEP 649

PEP 649 get > accepted: > Indeed -- that is the title of this thread, after all :-) And see others' notes, there seems to be two other places in the stdlib that will be affected. -CHB -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Softw

[Python-Dev] Re: PEP 563 and 649: The Great Compromise

y': int} In [22]: typing.get_type_hints(A) Out[22]: {'x': int, 'y': int} Then the only thing that would change with PEP 563 is the default behaviour. If I'm not mistaken, the complexity (and performance hit) of dealing with the whole could be string, could be object, eva

[Python-Dev] Re: PEP 563 and 649: The Great Compromise

or group 1 -- Type Checking seems to be of growing importance. Require only a small manageable update for group 2 -- important, but a smaller group of folks that would actually have to change code. (hmm.. maybe not -- not many people write libraries like Pydantic, but all the users of those l

[Python-Dev] Re: Keeping Python a Duck Typed Language.

gue that "the operation `isinstance(..., Sequence)` returns > `True`" is just another of the behavioral constraints that are > required to quack like a sequence. > I'm not sure of the definition of "nominal" typing -- but it absolutely is NOT duck typing (As L

[Python-Dev] Re: Keeping Python a Duck Typed Language.

essage/EGBSQALPGCTLAPM6FLIQLDV2YD2OLVAB/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython

[Python-Dev] Re: PEP 659: Specializing Adaptive Interpreter

I suggest we keep it really simple, and name the implementation. Building on Steve Holden’s suggestion: There is broad interest in improving the performance of the cPython runtime. (Interpreter?) -CHB -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific

[Python-Dev] Re: The repr of a sentinel

gt; > >>> MISSING() > Traceback (most recent call last): ... > TypeError: dataclasses.MISSING is a sentinel and cannot be instantiated > > - Tal > > > - Tal > ___ > Python-Dev mailing list -- [email protected]

[Python-Dev] Re: Critique of PEP 657 -- Include Fine Grained Error Locations in Tracebacks

FLB6QZX26E77O6QM/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython ___ Py

[Python-Dev] Re: PEP 659: Specializing Adaptive Interpreter

Python run faster isn't a worthy goal. -CHB -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython ___ Python-Dev mai

[Python-Dev] Re: The repr of a sentinel

Thanks Tal for writing this up. A couple comments: 1) "Add a single new sentinel value, e.g. MISSING or Sentinel" (under rejected) I was one of the proponent of that -- but not as an alternative to having a stadardars way to create unique sentinels, but as an addition. That's kind of orthogonal

[Python-Dev] Re: Roundup to GitHub Issues migration

> By contrast, requiring a github account for reporting bugs also makes> python an unwelcoming place for non-developers in general. Github is a> developers' social network, "mere" users are much less likely to want to> be part of it. Many will just silently abandon their bug report. But you do

[Python-Dev] Re: cmd.Cmd.prompt should be an instance attribute

EPUXXJFT5TMBUODIVL4CLR4O/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython __

[Python-Dev] Re: Is the Python review process flawed?

ibutors and maintainers, -CHB PS: All that being said, we, as a community, could do better. For instance, someone like me could do high-level triage on bug reports -- I need to set aside some time to do that. -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientif

[Python-Dev] Re: PEP 467 feedback from the Steering Council

> Python-Dev mailing list -- [email protected] > To unsubscribe send an email to [email protected] > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/[email protected]

[Python-Dev] Re: PEP 467 feedback from the Steering Council

with hex notation) I say it's not horrible, because bytes is a Sequence of bytes (or integer values between 0 and 255), initializing it with an iterable seems pretty reasonable, that's how we initialize most (all?) other sequences after all. And compatible with array.array and numpy a

[Python-Dev] Should PEP 8 be updated for Python 3 only?

obably too late for PEP 8 for those code bases anyway. If I make a PR, will it be considered? -CHB -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, sci

[Python-Dev] Re: Should PEP 8 be updated for Python 3 only?

to strike the paragraph that > links to reference [6]. > will do -- hopefully I'll find some time for this tomorrow. -CHB > On Tue, Aug 24, 2021 at 9:42 PM Christopher Barker > wrote: > >> I just noticed that PEP 8 has quite a few references to Python 2. Perhaps >&

[Python-Dev] Re: Should PEP 8 be updated for Python 3 only?

Open source projects with a global audience are encouraged to adopt a similar policy. """ But maybe we do want to keep comments, docstrings and literals as ASCII with escapes? -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Sc

[Python-Dev] Notes on PEP 8

Variables" and "Designing for Inheritance", the discussion of name mangling (leading __ names) is a bit redundant. Nothing incorrect or misleading -- just a copy-editing issue. Maybe I'll do a copy-editing PR -CHB -- Christopher Barker, PhD (Chris) Python Language Co

[Python-Dev] Re: Should PEP 8 be updated for Python 3 only?

/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/[email protected]/message/TWNYNKGCCMGNK4CXZGVZBCGCPQL7HMYF/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- Christopher Barker, PhD (Chris) Python Langua

[Python-Dev] Re: Should PEP 8 be updated for Python 3 only?

Thanks all. The PR is in process, and I believe it includes everything brought up here. If you have any more thoughts, please post them there. -CHB On Thu, Aug 26, 2021 at 1:54 AM Petr Viktorin wrote: > On 26. 08. 21 9:54, Marc-Andre Lemburg wrote: > > On 26.08.2021 06:07, Christoph

[Python-Dev] Re: PEP 467 feedback from the Steering Council

hon-Dev mailing list -- [email protected] > To unsubscribe send an email to [email protected] > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/[email protected]/message/TTFJ4VP5PCR557VHEH5LPS

[Python-Dev] Re: PEP 467 feedback from the Steering Council

) but I don't think we should say that particular use case is what bytes are targeted for. Anyone doing that should know what they are doing :-) -CHB -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Devel

[Python-Dev] Re: Regressions caused the recent work on ceval.c and frame objects

[email protected] > To unsubscribe send an email to [email protected] > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/[email protected]/message/TDGG4VFRZO5CDKTUH4AXYDLVXOKNLZZE/ > Code o

[Python-Dev] Re: Type annotations, PEP 649 and PEP 563

w many third party libs. So that may not be practical. -CHB -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython ___ Python

[Python-Dev] Re: Type annotations, PEP 649 and PEP 563

messages :-( My first choice would be to get a NameError at module load time, like we do now. Second would be a NameError as soon as it is accessed. Getting a special value is OK though, now that I'm thinking about it, I could probably put that special case code in one place, and provide

[Python-Dev] Re: Type annotations, PEP 649 and PEP 563

s that they want those uses to continue to be supported. -CHB -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython ___ P

[Python-Dev] Re: Python multithreading without the GIL

Skip > ___ > Python-Dev mailing list -- [email protected] > To unsubscribe send an email to [email protected] > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org

[Python-Dev] Re: Python multithreading without the GIL

fun to see David Beezley’s example from his seminal talk: > > https://youtu.be/ph374fJqFPE > Thanks, I'll take a look when I get a chance That may not be the best source of the talk -- just the one I found first :-) -CHB -- Christopher Barker, PhD (Chris) Python Language Cons

[Python-Dev] Re: Python multithreading without the GIL

x27;t be the first time. >> >> Skip >> >> P.S. I suppose I should have cc'd Sam when I first replied to this >> thread, but I'm doing so now. I figured my mistake would reveal itself >> early on. Sam, here's my first post about my little

[Python-Dev] Re: Having Sorted Containers in stdlib?

rtedDict would not be a bad way to go. Neither > would treap. > > > ___ > Python-Dev mailing list -- [email protected] > To unsubscribe send an email to [email protected] > https://mail.python.org/mailman3/lists/pytho

[Python-Dev] Re: Having Sorted Containers in stdlib?

On Tue, Nov 9, 2021 at 11:05 PM Paul Bryan wrote: > On Tue, Nov 09, 2021 at 10:01:35PM -0800, Christopher Barker wrote: > > What are use cases for sorted dicts? > > Good question :-) It could be handy for deterministic iteration of its values, for example to > allow seria

[Python-Dev] Re: Having Sorted Containers in stdlib?

ist -- [email protected] > To unsubscribe send an email to [email protected] > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/[email protected]/message/5SURNB4C5FGJ6LSXUPVW2EFP22ERKSGB/ > Code of Conduct: h

[Python-Dev] Re: Do we need to remove everything that's deprecated?

s no better reason than that, the change never should have been made. But once made, keeping multiple names around forever is not a good option. -CHB -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Developmen

[Python-Dev] Re: Do we need to remove everything that's deprecated?

aven’t looked) Deprecated code does normally more or less work, and often > it never gets close to dangerous behavior. On the flip side, it often > can cause dangerous behavior, I’m confused — did you mean "sometimes cause dangerous behavior"? That’s pretty rare isn’t it? -CHB

[Python-Dev] Re: Preventing Unicode-related gotchas (Was: pre-PEP: Unicode Security Considerations for Python)

stinguishing colors. Unlike the "ransom note" code above, code > highlighted in this way might even be quite pleasing to the eye. > > > > > > -- Paul McGuire > > > > > ___________ > Python-Dev mailing list -- python-dev@python

[Python-Dev] Re: Do we need to remove everything that's deprecated?

> if there are no actual code changes. But that's a fixed cost -- any maintained codebase is going to need updates and re-releases. I don't think anyone's suggesting that you do a release only to remove deprecations. For the example above -- if ALL you are doing is moving f

[Python-Dev] Re: Preventing Unicode-related gotchas (Was: pre-PEP: Unicode Security Considerations for Python)

ot; ("\N{LATIN > CAPITAL LETTER P}". > Is it possible to only capture things like the combining characters and not the "equivalent" ones like the above? -CHB -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Developme

[Python-Dev] Re: Preventing Unicode-related gotchas (Was: pre-PEP: Unicode Security Considerations for Python)

as no attribute 'print' In [62]: getattr(Junk, "print") Out[62]: 'print' Would a proposal to switch the normalization to NFC only have any hope of being accepted? and/or adding normaliztion to setattr() and maybe other places where names are set in code? -

[Python-Dev] Re: Do we need to remove everything that's deprecated?

really helpful in the 2-3 transition, and one nice thing about it is that it provided both translation ala 2to3 and compatibility ala six. -CHB -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development -

[Python-Dev] Re: The current state of typing PEPs

rly, in uncovering the use > cases we’re not aware of, and most importantly, being an interface to > typing enthusiasts Again -- is it only "typing enthusiasts" that you want to engage? Or "users of annotations"? -- maybe it is, but it would be nice if that was a

[Python-Dev] Re: The current state of typing PEPs

PEP 563 is that while typing is still optional, this is the first time that the language itself may be changed to accommodate typing -- so it can no longer be completely ignored. But dunders are the property of the language (or sometimes the > implementation), and they always have been. If you

[Python-Dev] Re: The current state of typing PEPs

e right in a phone) Maybe inspect.get_annotations() does, or will be able to, solve many of these issues. -CHB -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPy

[Python-Dev] Re: The current state of typing PEPs

e case is restricted. In fact, other than the basic core types, you need to use specialized types with this system anyway. -CHB -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development -

[Python-Dev] Re: The current state of typing PEPs

On Fri, Nov 26, 2021 at 5:47 PM Jim J. Jewett wrote:> Steven D'Aprano wrote:>> Maybe PEP 563 could include a decorator in the typing module to>> destringify all the annotations in a class or function?>> If it were in an annotations module, that would probably be sufficient.>> If it is in

[Python-Dev] Re: Optimizing literal comparisons and contains

http://python.org/psf/codeofconduct/ > > ___ > Python-Dev mailing list -- [email protected] > To unsubscribe send an email to [email protected] > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archiv

[Python-Dev] Re: Preventing Unicode-related gotchas (Was: pre-PEP: Unicode Security Considerations for Python)

XEJNYWVVR5LMFOM6M5ZB/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython

[Python-Dev] Re: The current state of typing PEPs

y -- so I suspect that the fact that he's taken an active role in developing static typing has influenced how it's being perceived. I do think this is a topic for the community to grapple with, but not really a Python-dev responsibility. -CHB -- Christopher Barker, PhD (Chris) Python Langu

[Python-Dev] Re: The current state of typing PEPs

A search of the repo issues indicates that there has been some discussion of PEP 563's impact, but it's not totally clear to me if it's been resolved. -CHB -- Christopher Barker, PhD (Chris) Python Language Consulting - Teachin

[Python-Dev] Re: Expectations of typing (was: The current state of typing PEPs)

Another concern I have is the over specification of types. I have seen many examples of, e.g. func(x: int, y: float, stuff: List(int]): but very few of: func(x: SupportsInt, y: SupportsFloat, stuff: Sequence[SupportsInt]): (or even Iterable[int]) Is that even the right thing to do to get gene

[Python-Dev] Re: Expectations of typing (was: The current state of typing PEPs)

; We should definitely push back on zealous new converts to typing who > insist that everything should be annotated. > well, we got folks wanting to change PEP 8 becuase they don't want their linter to complain -- so it will be a battle. > (Have you run into VS Code yet? It gets tremen

[Python-Dev] Re: Expectations of typing (was: The current state of typing PEPs)

go on your merry way -- e.g. duck typing, baby! Is there really no way to annotate that simply now? -CHB -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development

[Python-Dev] Re: The current state of typing PEPs

gation to provide any feature asked for, but a well-managed project will encourage useful contributions from users. -CHB -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scip

[Python-Dev] Re: Expectations of typing (was: The current state of typing PEPs)

ink it not only provides a transition, but also a future in which Path objects and string paths can continue to play well together. While Union[PathLike, str] is a pretty light lift, this is one tiny example of what we "typing skeptics" are concerned about: a transition away from full o

[Python-Dev] Re: The current state of typing PEPs

resent -- damn iPhone! On Thu, Dec 2, 2021 at 3:20 PM Christopher Barker wrote: > >for library authors. > > > > Providing high quality stubs and the best user experience is not easy. > > But I believe that referring people to typeshed can help. > > > This is a

[Python-Dev] Re: The current state of typing PEPs

till, maybe you have inadvertently listed everything that is agreed about > typing PEPs. 😂 > Rob Cliffe > > On 02/12/2021 23:20, Christopher Barker wrote: > > > >for library authors. > >> Providing high quality stubs and the best user experience is not easy. >&g

[Python-Dev] Re: The current state of typing PEPs

__ > Python-Dev mailing list -- [email protected] > To unsubscribe send an email to [email protected] > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/[email protected]/message/XR

[Python-Dev] Re: Should dataclasses add__set__ (and possibly __get __) descriptors ?

nt to: class Foo: def __init__(self, a=0): self.a = a Which behaves the same way when used the same way with Enum. So why should dataclasses be special in this particular way? -CHB -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Sof

[Python-Dev] Re: my plans for subinterpreters (and a per-interpreter GIL)

trefcount(None))" 4110 and a newly started iPython session: In [2]: sys.getrefcount(None) Out[2]: 28491 It does seem a bit silly to actually be tracking that refcount :-) -CHB -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Developm

[Python-Dev] Re: Python 3.10 vs 3.8 performance degradation

doing something different. Still to be discovered what that is. Note the OP: make sure that it's not as simple as a change to the default for the threads parameter. Note2: even if this is a regression cPython itself, I suspect the numpy list may be a better wey to get it figured out. -

[Python-Dev] Re: RFC on Callable Syntax PEP

there was a discussion a while back on python-ideas about extending the __getitem__ protocol, partly motivated by type hints. -CHB -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development -

[Python-Dev] Re: RFC on Callable Syntax PEP

type=hinting their production code bases could provide anecdotal evidence. Anyway, if my hypothesis is correct, then it's not so bad that not-so-nice syntax is required to type hint general purpose utilities. -CHB -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching

[Python-Dev] Re: RFC on Callable Syntax PEP

note: I wasn't thinking -- typeshed, of course, has a lot more than the standard lib. But it's still a collection of widely used somewhat general purpose libraries. So I think my hypothesis is still valid. -CHB On Sun, Dec 19, 2021 at 8:54 PM Christopher Barker wrote: > A quest

[Python-Dev] Re: Function Prototypes

Ronny Pfannschmidt > > "I find this unnecessary and unreadable. > > Python isn't C or Java." - BundleOfJoysticks (Reddit) > ___ > Python-Dev mailing list -- [email protected] > To unsubscribe send an email to pyth

[Python-Dev] Re: Suggestion: a little language for type definitions

gt; > ___ > Python-Dev mailing list -- [email protected] > To unsubscribe send an email to [email protected] > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/

[Python-Dev] Re: Suggestion: a little language for type definitions

string and other things, like [] might mean sometihng different. But in the end, if they are not going to be pre-processed, anon only allowed in annotations, then yes, no nead for the t"" at all. I think the first question is whether a typing language is a good idea at all -- then we ca

[Python-Dev] Re: Suggestion: a little language for type definitions

uot;readable" is more a matter of > familiarity than an inherent property of the language itself. With > enough familiarity, even APL is easy to read. > > > > If I > > had stumbled on it at 3.16 with samples, tutorials, and books all > infused > > with typing clutter

[Python-Dev] Re: Changing PySequence and PyMapping checks

ou're being thorough, should) define a type that only requires the methods that you need. I think MyPy's Protocol can be used for that, for example. -CHB -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Des

[Python-Dev] Re: Request to revert unittest and configparser incompatible changes in Python 3.11

to silence the ones I don't want. And it does prompt me to make sure that the upstream packages are working on it. Now we just need to get more people to use pytest :-) -CHB -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development

[Python-Dev] Re: Restated typing issue for class fields.

[email protected] > To unsubscribe send an email to [email protected] > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/[email protected]/message/ANSJXQTUQDGADZRLAV5YFRU74NHUBVBL/ > C

[Python-Dev] Re: Request to revert unittest and configparser incompatible changes in Python 3.11

n3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/[email protected]/message/HB4ZSI5UWSI3R3ASTIOCAYNU7YPBB57F/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- Christopher Barker, PhD (Chris) Python Language Consulting - Teachin

[Python-Dev] Re: Request to revert unittest and configparser incompatible changes in Python 3.11

warnings. Which is pretty easy to do with pytest, but maybe not so easy everywhere? > But we shouldn't just > dismiss warnings in those dependencies as "warnings I don't care about" > and ignore them as Not My Problem. > Unless we have done due diligence alr

[Python-Dev] Re: Please update Cython *before* introcuding C API incompatible changes in Python

n-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/[email protected]/message/EACB7ZZVDDNL4QAIODYDNWLKI455QDKP/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching -

[Python-Dev] Re: Please update Cython *before* introcuding C API incompatible changes in Python

On Tue, Feb 1, 2022 at 3:22 PM Greg Ewing wrote: > On 2/02/22 11:53 am, Christopher Barker wrote: > > As a long time Cython user, but not a Cython developer, I think (2) is > > the primary purpose, with (1) as a handy side benefit (otherwise > > we'd just use ctypes, y

[Python-Dev] Re: Please update Cython *before* introcuding C API incompatible changes in Python

python.org/message/KTWDJGHPQW7AIKDQQYV4IFHAKQZVXACL/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cy

[Python-Dev] Re: Please update Cython *before* introcuding C API incompatible changes in Python

p to make it easy to set - e.g a flag to cythonize or something. -CHB -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scip

[Python-Dev] Re: Slowly bend the C API towards the limited API to get a stable ABI for everyone

a conda-forge-like auto-build system is inherently easier for conda packages than binary wheels. Which doesn't mean it couldn't be done -- just that the challenge of third party libs would need to be addressed. In any case, someone would have to do the work, as usual. -CHB -- Christoph

[Python-Dev] Re: PyPy on PySide6 is there: PyPy with a Gui

? or computing the mandelbrot set, for which I would expect to see performance numbers like that. Anyway, really cool in any case -- a major step for PyPy. -CHB -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI a

[Python-Dev] Re: Should we require IEEE 754 floating-point for CPython?

he main platform that this was an issue for, for computationally heavy code, was Cray -- but it seems they're 754 compatible now, yes? Thanks for doing this, -CHB -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop G

[Python-Dev] Re: It's now time to deprecate the stdlib urllib module

shingly long time! So I'd think cPython release Cycle shold be able to keep up with all but the very latest. > make Python less attractive and less useful for beginners. On this point, I'm not so sure -- the first thing I do for beginners is to point them to requests, as it's ea

[Python-Dev] Re: An unambiguous way of initializing an empty dictionary and set

t compelling here. set() is (maybe?) the only builtin, but is initializing and empty set that common? Note, there was a recent thread on this list about a literal for frozenset — I think: f{} was proposed— you may want to revive that -and add s{} for an empty set ... Though i personally wouldn’t supp

[Python-Dev] Re: An unambiguous way of initializing an empty dictionary and set

Oops, didn’t notice this wasn’t Python-ideas — that’s where it should be. -CHB On Sun, Mar 13, 2022 at 3:44 PM Christopher Barker wrote: > > Possible solution: >> s = {} # new empty set >> d = {:} # new empty dictionary (the ":" is a reference to key-value pairs)

[Python-Dev] Re: Are "Batteries Included" still a Good Thing? [was: It's now time to deprecate the stdlib urllib module]

to actually implement some of those. (but yes, that's a lot of work that someone(s) would have to do) Back to the topic at hand, rather than remove urllib, maybe it could be made better -- an as-easy-to-use-as-requests package in the stdlib would be really great. -CHB -- Christopher B

[Python-Dev] Re: Are "Batteries Included" still a Good Thing? [was: It's now time to deprecate the stdlib urllib module]

ould be nice to see it addressed somewhere -- a grand unification of JSON libs. In short: I think I agree with most folks here that we should still include the batteries, and they should be updated / maintained to some extent. What exactly could/should be done is going to have to be worked

[Python-Dev] Re: Are "Batteries Included" still a Good Thing? [was: It's now time to deprecate the stdlib urllib module]

ithout the bandwidth to actually shepherd the project, but if someone wants to, I think it would be a great idea. -CHB -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scip

1 2 >