Yep, fine with me too.
-Barry
> On Nov 13, 2023, at 02:17, Marc-Andre Lemburg wrote:
>
> Hello everyone,
>
> for quite a while now, core discussions have moved to Discourse and people
> are obviously enjoying things there:
>
> https://discuss.python.org/c/core-d
y deduced. Am I missing something?
Try asking for help at https://discuss.python.org/
This list is not for help or ideas, also its basically dead.
Barry
>
> --
> Christian Tismer-Sperling:^) tis...@stackless.com
> Software Consulting : http://www.stackless.com/
>
I heard it on reasonably believable authority that the FLUFL took the year off.
Lamentable.
-Barry
> On Apr 1, 2023, at 11:19, Skip Montanaro wrote:
>
> Just wanted to throw this out there... I lament the loss of waking up on
> April 1st to see a creative April Fool's D
to python and back into C++ and the exception arrives
as expected.
You can riase in Python fo into C++ and back to Python and again the exception
arrives as expected.
That is as long as its a python exception.
Barry
> ___
> Python-Dev mailing l
> On 11 Dec 2022, at 21:05, Abdur-Rahmaan Janhangeer
> wrote:
>
> If only, fellow list colleagues, I could see only the topics I choose on
> Discourse.
Have you tried changing the Preferences for Notifications/Categories?
That would appear to give you the control you are ask
responded to. I might drop in
to those a couple of times a day when things are slow. Then of course there’s
Discord for various Python groups, and Python’s Slack.
The whole shift away from email leaves me calmer and better engaged.
-Barry
> On Dec 9, 2022, at 06:49, Stephen J. Turnb
n just yet, but it sure
is nice to not be overwhelmed and stressed out every single day by the bloat in
my Python inbox.
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe
k last week and decided to take a shot at it and have
> built something that I feel is a bit ugly but does seem to work. I'd like to
> some feedback on this approach.
We use the pyOpenSSL to access APIs of openssl.
No need to use ctypes.
Barry
>
> My patches can be fo
Oh, I see, thanks. This is for the email interface, not the web interface.
-Barry
> On Sep 27, 2022, at 13:49, Cameron Simpson wrote:
>
> On 27Sep2022 11:14, Barry Warsaw wrote:
>>> Threading on the Python Discourse should now be working correctly. This is
>>&
g that previous
discussions get for free or only new replies? I’m not finding much information
about this feature on the Discourse site.
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list -- python-dev@python.
c. But
> for PEP-level changes, we believe python-dev no longer reaches the proper
> audience.
Please also make sure your PEP’s Discussions-To header points to the right
forum.
https://peps.python.org/pep-0001/#discussing-a-pep
Cheers,
-Barry
signature.asc
Description: Mess
nts `\0x0b', as it does in the re module.
You seem to be mixing the use \ as the escape for strings and the \ that re
uses.
Is it the behaviour that '\' becomes '\\' that means this is
a breaking change?
Won't this work?
```
re.compile('\v:\\v')
# which is
To me, that’s the biggest negative of Discourse, and I definitely prefer
threaded discussions. Unfortunately though, much like top posting , I
think that horse is out of the barn, what with other forums like GitHub being
linear.
-Barry
On Jul 15, 2022, at 11:59, Ethan Furman wrote:
>
&g
. What similar kinds of protections do we have on
Discourse?
-Barry
> On Jul 15, 2022, at 04:18, Petr Viktorin wrote:
>
> The discuss.python.org experiment has been going on for quite a while, and
> while the platform is not without its issues, we consider it a success. The
> C
unchanged here. I also am struggling to think of a place
> where someone would care about the kernel-level changes between _MOD
> and _ADD/_DEL but that might be my own lack of imagination or
> knowledge of epoll techniques.
>
> Maybe a compromise is to ship EpollExclusveSelector for a rel
save from austinp
itself?
Barry
___
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
https://mail.python.org
> On 27 Apr 2022, at 20:21, Miro Hrončok wrote:
>
> On 27. 04. 22 20:45, Barry wrote:
>>> On 27 Apr 2022, at 17:22, Victor Stinner wrote:
>>>
>>> Ok, you changed my mind and I added PYTHONDONTADDPATH0=1 env var. Example:
>> Maybe the env var say
> On 27 Apr 2022, at 17:22, Victor Stinner wrote:
>
> Ok, you changed my mind and I added PYTHONDONTADDPATH0=1 env var. Example:
Maybe the env var say what it is not adding rather then where it adds it.
PYTHONDONTADDPWD=1
Barry
___
P
alue__',
'__forward_is_argument__', '__forward_is_class__',
'__forward_module__’)
So it seems that you’re almost there already!
> So, technically, this means we could spell the "continue class" step like so:
>
> c
#x27;s
> interested in this and happens to be in the sprints too!
>
> I am and I will be.
Apologies for the icky quoting, but yay! It’s great to hear your intentions,
and like Guido, I would like to connect on this at Pycon as well.
-Barry
119
I’ve put some questions and comments there, but I’m also really curious about
the technical details for your lazy imports. Have you gotten as far as
thinking about a PR or PEP?
-Barry
[1] Not that there aren’t other reasons folks give for rewriting, such as
multicore performance
.
However, if start up time isn’t a direct benefit of on-demand imports (a.k.a.
declarative imports), I’m not sure how actually useful or used they will be. I
dunno, top-of-module imports never really bothered me that much.
-Barry
[1] I could be wrong about Faster CPython; ISTR there are some tickets
but I’m like Guido. I pretty much use
pytest for everything these days, except for maybe unittest.mock.patch.
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send
arately on PyPI. It’s *possible*
but I don’t know if it’s *practical*.
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://ma
discussions. This will make reading and authoring PEPs a much nicer experience.
Cheers,
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le
lace the libexpat code inside the python tree
then compile python and see if that works without error.
Take that python version and run the python test suite against it.
If that passes then I would run my application’s test suite to ensure no
regressions.
Barry
>
> Thanks,
> Raghu
&g
to link python to an external libexpat instead of the
vendored expat inside python?
Have you tried deleting libexpat 2.2.8 from the python source code and
replacing with the libexpat 2.4.6 and then
compiling python?
Are you concerned that you need fixes in the python c
Should is often read as meaning optional when writing specs.
Can you say “must be compatible with C++”.
Barry
>
> Victor
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@pytho
it will likely get more traction over time. The disadvantage is that HPy
would evolve at the same annual pace as CPython.
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe se
> On 20 Jan 2022, at 02:22, Skip Montanaro wrote:
>
> (This really belongs on python-ideas, right?)
>
I'm commenting on the implementation that is on going. python-ideas does not
seem right.
Barry
___
Python-Dev mailing l
> On 19 Jan 2022, at 21:19, Ethan Furman wrote:
>
> An environment variable would solve this, yes? The default would be using
> the underlining carets, but an env var could switch that to using color
> instead.
Oh and if you use colours then you please give me the ability to set the
colour
> On 19 Jan 2022, at 21:19, Ethan Furman wrote:
>
> On 1/19/22 1:10 PM, Barry Scott wrote:
> > On 18 Jan 2022, at 19:59, Pablo Galindo Salgado wrote:
>
> >> We considered using colours and other markers such as bold text, but that
> >> opens a considera
dded escape sequences without a way to turn then off in the API.
On the other hand it would be great to be able, as an API call, to set the
style of the traceback
text.
Barry
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an e
recompiling the source file you're
> staring at. Which it recomplies without benefit of PGO.
The trick you need is to close the project you use to build python
from source then you can open the python.exe and run that under the
debugger. Because it can find the python.pdb it will source/d
PEPs are simple and regular enough that a good
local build environment can suffice for now.
Cheers,
-Barry
> On Jan 10, 2022, at 02:44, pyt...@quite.org.uk wrote:
>
> Hi,
>
> I would like to announce PEP 676 to python-dev. It is a meta-PEP focussed on
> modernising the PEP bu
, ultimately.
-Barry
On Sat, Jan 8, 2022, at 03:06, Stéfane Fermigier wrote:
>
> On 8 Jan 2022 at 00:59:38, jack.jan...@cwi.nl wrote:
>>
>> I posted this suggestion earlier in the callable type syntax discussion, at
>> which point it was completely ignored. Possibly because it’s
/4TY3MVJQOLKSTMCJRTGAZEOSIIMAWQ45/
Of course, this decision can be revisited by the 2022 SC.
-Barry
> On Jan 7, 2022, at 15:59, jack.jan...@cwi.nl wrote:
>
> I posted this suggestion earlier in the callable type syntax discussion, at
> which point it was completely ignored. Poss
ame that is easier to understand.
So it might be CostFunction that would be a great name in that problem domain.
Barry
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.o
s:
>
> ```
> def SomeFn(x: float) -> int:
> ...
>
> def twice(f: SomeFn) -> SomeFn:
> return lambda x: f(f(x))
> ```
That seems pretty intuitive to me. The conventions you mention would be just
that though, right? I.e. `pass` could be used, but whatever the body is it
wo
On Dec 20, 2021, at 12:22, Guido van Rossum wrote:
> What do you think about -hh (and maybe —help-full) printing full help?
>
> Is there enough of a use case for this to bother?
Maybe not. I’d say if it was easy to implement, why not, but if it’s a pain,
don't bother.
-Barry
on)
>
> Two lines printed at the end of the -h/--help output would refer users to
> --help-env and -Xhelp.
+1, and —help-env seems better.
What do you think about -hh (and maybe —help-full) printing full help?
-Barry
signature.asc
Description:
On Nov 29, 2021, at 15:57, Larry Hastings wrote:
>
> On 11/29/21 2:56 PM, Barry Warsaw wrote:
>> PEP 563 and 649 have visible effects that even within that domain can have
>> important side effects. For example, PEP 563’s loss of local scope, which
>> even “de-stri
As much as I’m in the "type annotations are
good” crowd now, I still think they should always be optional. Python’s use is
so broad these days, I for one don’t want to have to add annotations to every
bit of Python I write.
-Barry
signature.asc
Description: Message signed with OpenPGP
the types declared in annotations to affect
> runtime behaviour, as that's the most under-represented group at the
> moment (and it's not clear whether it's under-represented because
> there aren't many such uses, or because the users aren't being heard
> fro
they don’t speed things up as much as you think they will.
Optimizations usually involve adding complexity. I would like some sense of
what we’d gain for the added complexity.
Cheers,
-Barry
> On Nov 29, 2021, at 09:04, Serhiy Storchaka wrote:
>
> 29.11.21 18:36, Victor Stinner пиш
exemption in
https://github.com/python/steering-council/issues/80
Respectfully,
-Barry (on behalf of the Python Steering Council)
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https
a PEP Delegate, but more than a PEP shepherd. If
you are that person, please let us know!
Cheers,
-Barry (on behalf of the Python Steering Council)
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le
3.11 at your convenience.
With our appreciation,
-Barry (on behalf of the Python Steering Council)
___
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
Thank you Sam, this additional detail really helps me understand your proposal.
-Barry
> On Oct 11, 2021, at 12:06, Sam Gross wrote:
>
> I’m unclear what is actually retried. You use this note throughout the
> document, so I think it would help to clarify exactly what is ret
?
Cheers,
-Barry
> On Oct 7, 2021, at 12:52, Sam Gross wrote:
>
> Hi,
>
> I've been working on changes to CPython to allow it to run without the global
> interpreter lock. I'd like to share a working proof-of-concept that can run
> without the GIL. The proof-of-conce
constraint?
Hi Sergei. I don’t mean anything more than just that there should be a single
syntax for all of Python. I was just trying to describe “the bits of Python
that aren’t type annotations”.
Cheers,
-Barry
signature.asc
Description: Message signed with OpenPGP
___
the kind of analysis the PSC needs in order to weigh the cost and
benefits of making such changes to Python.
TL;RA - One Syntax to Rule Them All
Cheers,
-Barry
> On Oct 7, 2021, at 09:41, S Pradeep Kumar wrote:
>
> Hello all,
>
> Typing-sig has been discussing user-friendly synt
own that "except group" has
> ambiguous edge cases the proposals have gotten worse, which to me is a good
> sign that we need to stop.
With async it goes *before* def, for, with.
Can you put the group before the except in the same style?
try:
stuff...
group except :
han
That might be exceptable.
-Barry
> On Oct 6, 2021, at 08:59, Brandt Bucher wrote:
>
> Łukasz Langa wrote:
>> Joking aside, since we allow any expression after 'except' 'group' then this
>> is indeed ambiguous. In theory!
>
> Another option
What do the PEP authors think about `except group`? Bikeshedding aside, that’s
still the best alternative I’ve seen. It’s unambiguous, self-descriptive, and
can’t be confused with unpacking syntax.
-Barry
> On Oct 5, 2021, at 11:15, sascha.schlemmer--- via Python-Dev
> wrote:
>
What do the PEP authors think about `except group`? Bikeshedding aside, that’s
still the best alternative I’ve seen. It’s unambiguous, self-descriptive, and
can’t be confused with unpacking syntax.
-Barry
> On Oct 5, 2021, at 11:15, sascha.schlemmer--- via Python-Dev
> wrote:
>
We could of course bike shed on the syntax forever. The PSC did vote to accept
the PEP but we left room for changes while during the 3.11 cycle.
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list -- python-de
that
same mechanism?
Will `make test` and/or CI run Python with both options? How will we make sure
that frozen modules (or not) don’t break Python?
Option #3 seems like the most reasonable one to me, with the ability to turn it
on when running from the source tree.
-Barry
> On Sep 27, 2021,
ghlighting can extend deep into the
file.
speaking-for-all-3-of-the-remaining-emacs-users-ly y’rs,
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to p
-be-the-default-value-for-int-to-bytes-byteorder/10616
Cheers,
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https
Adding default arguments to int.to_bytes() is both useful on its own merits and
kind of too easy *not* to do, so...
https://bugs.python.org/issue45155
https://github.com/python/cpython/pull/28265
-Barry
> On Sep 9, 2021, at 12:12, Barry Warsaw wrote:
>
> Signed PGP part
> On Sep
On Sep 9, 2021, at 10:56, Ethan Furman wrote:
>
> On 9/9/21 9:37 AM, Barry Warsaw wrote:
>
> > While I think int.to_bytes() is pretty obscure (I knew about it, forgot
> > about it, and learned
> > about it again!) I’m not so sure it’s any less obscure than a
(length=1, byteorder=sys.byteorder, *, signed=False)
Then I ought to be able to just do
>>> (65).to_bytes()
b’A’
and if I try to convert an integer value greater than 255, I get the same
OverflowError?
Seems good enough to me.
-Barry
> On Sep 9, 2021, at 08:53, Christopher B
On Sep 9, 2021, at 08:53, Christopher Barker wrote:
>
> I fully admit serious bikeshedding here, but:
I think you meant “byte-shedding” :D
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list -- pyth
> On 8 Sep 2021, at 06:39, Steven D'Aprano wrote:
>
> On Tue, Sep 07, 2021 at 08:09:33PM -0700, Barry Warsaw wrote:
>
>> I think Nick is on board with bytes.fromint() and no bchr(), and my
>> sense of the sentiment here is that this would be an acceptable
t this would be an acceptable resolution for most
folks. Ethan, can you reconsider?
Cheers,
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-
rmine what’s right for them, their
teams, or their projects.
Cheers,
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@pytho
es.
When the SC was considering all these PEPs for 3.10, we felt like we needed
clarity on the direction and purpose of type annotations before we could make
decisions we’d have to live with essentially forever.
Cheers,
-Barry
signature.asc
Description: Message
m not a fan of smushedwords but .fromint()
seemed better than .fromord().
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.or
t; some_var = bytearray(bchr(65))
> vs
> some_var = bytearray.from_int(65)
Can you provide some rationale for why you prefer bchr() over .fromint()?
Cheers,
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list
Thanks Nick. Ethan, what do you think?
-Barry
> On Jul 29, 2021, at 16:28, Nick Coghlan wrote:
>
>
>
> On Fri, 30 Jul 2021, 8:47 am Barry Warsaw, wrote:
>
> Hello Nick, Ethan,
>
> The Python Steering Council reviewed PEP 467 -- Minor API improvements for
>
exists only for the symmetry described in the PEP is
just a little extra complexity for little value.
Let us know what you think about making these changes. We aren’t making
acceptance contingent on these changes, but we do think they make the PEP and
the new APIs better.
-Barry (on behalf of the
On Jul 29, 2021, at 05:55, Steve Dower wrote:
>
> Maybe we should have a "Type" other than Standards Track for PEPs that are
> documenting implementation designs, rather than requirements for
> standardisation?
Wouldn’t Informational fill that need?
-Barry
sig
As specifically to the flaws in our workflow and the backlog, this is exactly
what the Developer-in-Residence program was designed to address:
https://pyfound.blogspot.com/2021/04/the-psf-is-hiring-developer-in.html
Stay tuned!
-Barry
> On Jun 29, 2021, at 09:56, Joannah Nanjekye wr
to the Python 3.9 behavior, and that a PEP be written for Python 3.11.
Cheers,
-Barry (on behalf of the Steering Council)
> On Jun 28, 2021, at 00:56, Ethan Furman wrote:
>
> I have spoken with Pablo (3.10 RM), and he agrees that a change to Enum str()
> in 3.10 and another in
On Jun 29, 2021, at 08:27, Mark Shannon wrote:
>
> I was expected the announcement of a BDFL delegate for PEP 657, as the author
> is a steering council member.
PEP Delegates are not required, even when the PEP author is an SC member.
-Barry
signature.asc
Description: Message si
I’m happy to announce that PEP 657 (Include Fine Grained Error Locations in
Tracebacks) has been unanimously accepted for Python 3.11 by the Python
Steering Council.
Congratulations Pablo, Batuhan, and Ammar!
Cheers,
-Barry (on behalf of the Steering Council)
signature.asc
Description
es due to these
DeprecationWarnings. I defer to the RM but Pablo already approved it. :D
https://github.com/python/cpython/pull/26882
adds import time DeprecationWarnings to asyncore, asynchat, and smtpd.
Cheers,
-Barry
signature.asc
Description: Message signed with OpenPGP
___
That sounds great, thanks Mariatta.
-Barry
> On Jun 23, 2021, at 12:36, Mariatta wrote:
>
> My understanding is that Ezio is/will be working on updating PEP 588.
> Last I heard from Ezio is that he would be co-author of PEP 588 and he would
> be updating it/rewrite it to b
Miro, what tests (outside of Python itself) do you think may break, and do you
have a way to check that?
-Barry
On Wed, Jun 23, 2021, at 17:15, Miro Hrončok wrote:
> On 23. 06. 21 23:49, Irit Katriel via Python-Dev wrote:
> >
> > Barry and I are working on a patch to add depre
and the fact that Ezio is managing the project elsewhere, I think rejection
is appropriate. However if we do that I think the PEP should at least be
updated with references to Ezio’s project, with some verbiage added as to why
these changes are being made.
What do you think, Mariatta?
-Bar
tps://docs.gitlab.com/ee/user/project/import/github.html
Of course, that would still be infrastructure we’d have to run (unless we used
gitlab.com, but then some people might still object), and that migration would
also have to deal with Roundup issues if we don’t complete that migration.
-Barry
I think it makes sense, and I do see a difference between Provisional and
Unstable. Is this anything more than a documentation label?
-Barry
> On Jun 3, 2021, at 13:10, Guido van Rossum wrote:
>
> This is not a complete thought yet, but it occurred to me that while we have
> dep
not pass this argument”
construct would have to work with the Optional type too.
The other use case I have for a special case single use singleton is for
dict.get(), i.e.
missing = object()
value = somedict.get(‘key’, missing)
if value is missing:
# It ain’t there.
-Barry
signature.asc
Descriptio
helpful in that situation,
Most tools that support colour output allow you to customise the colours
and have a always-colour, never-colour, auto-colour option.
Isatty() is useful for the auto.
Barry
>
> -Mike
>
> ___
> Python-Dev mai
>> Slapping my forehead,
>
> You probably mean "Slap my forehead”.
Actually, he probably meant “Slappa da bayss”.
-Barry
P.S. I was going to say that I prefer past tense when writing news items, but
then I looked at the change log files for some of my personal projects and I
/OGYZZZ4A54RI24YEKZEPPLWU4WPRLJPE/
We on the SC extend our thanks again for the PEP, and encourage you to continue
to work on this PEP for pronouncement in Python 3.11.
Cheers,
-Barry
(on behalf of the Python Steering Council)
signature.asc
Description: Message signed with OpenPGP
eries of curated videos under the Python/PSF
banner would be awesome.
Cheers,
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
on’t know whether I’ll have time to *start* something any time soon, but I
would also volunteer to be a reviewer and/or provide some content.
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list -- python-dev
(this whole topic is on our agenda for next Monday), but it might be the
best thing to do given where we are in the 3.10 release cycle. It would give
everyone a chance to breathe and come up with the right long term solution.
Cheers,
-Barry
signature.asc
Description: Message signed with O
On Apr 15, 2021, at 09:54, Antoine Pitrou wrote:
>
> On Thu, 15 Apr 2021 09:38:41 -0700
> Barry Warsaw wrote:
>> On Apr 14, 2021, at 23:11, Christopher Barker wrote:
>>>
>>> You wrote the original PEP, so of course you can withdraw it (or reject
>>&
g a new PEP and referring back to 396.
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/li
making that change. importlib.metadata is a much better
approach to programmatically determining package versions.
https://docs.python.org/3/library/importlib.metadata.html#distribution-versions
-Barry
signature.asc
Description: Message signed
n parameter or
> function return value must be specified?) Some of us don't use type hinting
> or annotations (I don't even pretend to understand what they are) and don't
> intend to. No offence to those who like them, carry on doing your thing.
> Please reassure
nting in Python.
-Barry
signature.asc
Description: Message signed with OpenPGP
___
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/
Mess
le example! Who’s maintaining the list? :D
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailma
a little ecosystem of
its own, and given that many Python users are still not fully embracing typing,
maybe continuing to tie the typing syntax to Python syntax is starting to
strain.
Cheers,
-Barry
signature.asc
Description: Message signed with OpenPGP
___
perhaps you could add some language to the Rejected Ideas about it. Ultimately
we couldn’t come up with anything better, so we decided that the PEP as it
stands solves the problem in a practical manner, and that this is for the most
part a wart that users will just have to learn and internal
his would be a hard nut to crack.
def func(fixed, *args):
print("my func", fixed, args)
Barry
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mai
pth files and finding something
better, but maybe not.
In any case, this is outside the scope of PEP 648 so just pretend that part
wasn’t in my response.
-Barry
> On Mar 30, 2021, at 17:00, Pablo Galindo Salgado wrote:
>
> Hi Nick,
>
> Please don't, since that would for
1 - 100 of 2826 matches
Mail list logo
