rrupt(), KeyboardInterrupt()])
> # propagates further, a traditional "except KeyboardInterrupt"
> # would catch it. The ValueError is discarded.
>
> An interesting feature would be: when the matching clause has no "as",
> "except" behaves the s
BaseException)" as a rejected idea and
explain it there.
_______
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
ring the migration/mixed python version phase. But I'm not
convinced yet that this is what we want to end up with in the long term.
Waiting to hear more thoughts.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to pyth
foo, foo)
See PEP461:
Adding % formatting to bytes and bytearray
<https://www.python.org/dev/peps/pep-0461/>
"With Python 3 and the split between str and bytes, one small but
important area of programming became slightly more difficult, and much
more painful -- wire format protocols."
nge whatsoever
(are disadvantaged people's lives going to be improved by this
rename?). What next? Are we going to crack down on any courses that
proclaim to help you to "master the Python language"? Does that, too,
have to be renamed?
ChrisA
____
I think https://mail.python.org/archives/list/python-dev@python.org/message/GDAUZKYB6GP3A3ZGBSQ4KQ7R6QFIZHZC/ and
https://mail.python.org/archives/list/python-dev@python.org/message/RE3V6Y7CPHOL6LGPPYSVS3XQFTIQRZ3J/ already explained the reasons in
sufficient detail -- that "main&
cluding Notepad!) to use the encoding we want.
I don't see a problem with using a file encoding specification like in Python
source files.
Since site.py is under our control, we can introduce it easily.
We can opt to allow only UTF-8 here -- then we wait out a transitional period and di
On 17.03.2021 23:04, Steve Dower wrote:
On 3/17/2021 7:34 PM, Ivan Pozdeev via Python-Dev wrote:
On 17.03.2021 20:30, Steve Dower wrote:
On 3/17/2021 8:00 AM, Michał Górny wrote:
How about writing paths as bytestrings in the long term? I think this
should eliminate the necessity of knowing
probably opens new possibilities for adoption strategies of exception
groups and except* (in terms of the interaction of exception groups with
except).
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le
e time over the next couple of weeks, please take a look at the
current draft and let us know your thoughts:
https://www.python.org/dev/peps/pep-0646/ (Note that the final couple of
sections are out of date; https://github.com/python/peps/pull/1880
clarifies which grammar changes would be required,
fully this is because everyone thought they are
sensible.
Irit, Yury and Guido
_______
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.or
wrote:
Hi,
tl;dr Tests of the Python Test Suite now start with 131 imported
modules, instead of 233. For example, asyncio, logging,
multiprocessing and warnings are no longer imported by default.
--
The Python test suite is run by a custom test runner called
"libregrtest" (test.libregr
performance
2) Maintainability - no code duplication in favor of using reusable classes
3) RAII - Resource Acquisition Is Initialization, predictable allocation and
free resources
...
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an
On 24.03.2021 19:58, Antoine Pitrou wrote:
On Wed, 24 Mar 2021 19:45:49 +0300
Ivan Pozdeev via Python-Dev wrote:
How does C++ fare in binary compatibility? Last time I checked it out (about 10
years ago), there was completely none, every compiler's ABI
was a black box without any guara
g the
> language) adhoc concept they need.
>
> So, let's look how the usual "except MyExc as e" works: it performs
> "isinstance(e0, MyExc)" operation, where e0 is incoming exception
> (roughly, sys.exc_info[1]), and if it returns True, then assigns e0 to
> the "
; that you are using the builtin one.
> >
> > I see the aesthetic value of your suggestion, but does it have
> > practical advantages in light of the above?
>
> The concern is that it codifies pretty complex and special-purpose
> things on the language level. And it seems that
ur concern with our design is that ExceptionGroup implements a generic
split() that handles tracebacks and nested structure correctly, and you
might not need that because maybe you don't nest or you don't care about
tracebacks?
If that is the case then I think you are confusing "g
re automatically reraised.
You can see the trio code for that here:
https://github.com/python-trio/trio/blob/master/trio/_core/_multierror.py#L129
The trick it does to reset __context__ in the finally block won't work for
the __traceback__ (I tried). So it always adds the current frame (if it
act of
> life that in a concurrent program, multiple things can go wrong at once,
> and we want Python to be usable for writing concurrent programs. Right now
> the state of the art is "exceptions in background threads/tasks get dropped
> on the floor", and almost anything is
e the nodes represent the times when
exceptions were grouped together and raised.
Irit
___
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.p
this:
<<<<<<< issue-43737
.. productionlist::
lambda_expr: "lambda" [`parameter_list`]: `expression`
lambda_expr_nocond: "lambda" [`parameter_list`]: `expression_nocond`
===
.. productionlist:: python-grammar
lambda_expr: "lambda" [`parameter_
ontext management
>
> I'd like to address and get feedback on the context management issue.
>
> ```python
> from tempfile import NamedTemporaryFile
>
> with NamedTemporaryFile() as fp:
>fp.write(b'some data’)
fp.flush(). # needed to ensure data is
2:42, Ethan Furman wrote:
On 4/8/21 1:43 PM, Antoine Pitrou wrote:
On Thu, 8 Apr 2021 13:31:26 -0700
Ethan Furman wrote:
```python
from tempfile import NamedTemporaryFile
with NamedTemporaryFile() as fp:
fp.write(b'some data')
fp.close() # Windows workaround
fp.open()
ss and get feedback on the context management issue.
```python
from tempfile import NamedTemporaryFile
with NamedTemporaryFile() as fp:
fp.write(b'some data')
fp = open(fp.name())
data = fp.read()
assert data == 'some_data'
```
Occasionally, it is desirable to close
=== TypeCategory.None;
}
```
-Eric
On 4/6/21, 1:31 PM, "Barry Warsaw" wrote:
The Python Steering Council reviewed PEP 647 -- User-Defined Type Guards, and
is happy to accept the PEP for Python 3.10. Congratulations Eric!
We have one concern about the semantics of the PEP however. In a sense
Hi Larry,
On 4/12/21, 6:57 PM, "Larry Hastings" wrote:
Again, by "works on PEP 563 semantics", you mean "doesn't raise an error".
But the code has an error. It's just that it has been hidden by PEP 563
semantics.
I don't agree that chang
On 13/04/2021 23:21, Barry Warsaw wrote:
I would still be opposed to requiring type hinting in Python.
-Barry
(Gasps in horror.) I can only hope I've misunderstood this sentence.
Has it ever been even tentatively suggested that type hinting become
mandatory? (What would that even
so far, nobody has
> suggested even minor changes. Folks have just expressed their opinions about
> it (which is fine).
This is not true. I suggested yesterday (in
https://mail.python.org/archives/list/python-dev@python.org/message/DSZFE7XTRK2ESRJDPQPZIDP2I67E76WH/
) that PEP 649 could av
och/
>
> Standardized by whom? This is not a POSIX nor Windows standard at
> least. Just because a Web page claims it is standardized doesn't mean
> that it is.
>
>> More and more projects adopted it. As I wrote, the Python stdlib
>> already uses it in compilea
out the timing --
> not just because there is still some discussion going on, but also the time
> available for us to discuss the proposal, and to validate the new API once
> it’s accepted. We are rapidly approaching feature freeze for Python 3.10,
> and while we’re not particularly
NINGS
environment variable to use the message as a regular expression in
Python 3.10. Or does anyone have a reason to keep the current behavior
as it is?
I created https://bugs.python.org/issue43862 for this change.
--
Python provides two ways to specify warnings filters:
* -W command line o
nobody" - well, I knew that already. 😁
² Your idea of "large" may not be the same as mine - I'm talking a few
thousand lines.
_______
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...
fining a new kind of traceback entry, I was storing this on the EG
> itself, so that's why I was thinking about it needing to be part of
> this PEP.
>
You can also create an ExceptionGroup subclass with whatever extra data you
want to include.
Irit
___
Python-Dev mailing list --
in the PEP:
>
> Why not extending BaseException by __group__ among __cause__ and __context__?
>
> Would this reduce some of the added complexity and thus increase broader
> acceptance?
>
> Cheers,
> Sven
___________
Python-Dev mailing
on in the PEP:
>>> Why not extending BaseException by __group__ among __cause__ and
>>> __context__?
>>> Would this reduce some of the added complexity and thus increase broader
>>> acceptance?
>>> Cheers,
>>> Sven
>
___
Python-Dev mailing list -- p
new API when you start raising exception groups from a
function because that changes the function's external behaviour.
-1 from me on the denormalized traceback idea. I've said what I had to say
about it in my previous email.
Cheers
Irit
____
at (ie no nesting of EGs) or just the traceback to be flat (but you
can still have a nested EG). I also don't know what problem you are trying
to solve with this.
Fortunately we're not at the whiteboard stage anymore, we have a fully
working implementation and you can use it to demonstrat
Thanks for the feedback, Brett! This is a very reasonable response given
the implications of a syntax change. We'll work on a more thorough
implementation and add details to the PEP of the grammar changes that are
necessary, and see you again in the cycle for Python 3.11.
On Fri, 23 Apr 20
deprecate the old macros?
Irit
___
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/archives
This is just what I needed, thanks!
I’m in the process of preparing a presentation for my team at Bank of America
about how the dev lifecycle of our system (Quartz risk platform) interplays
with the dev lifecycle of Python (and how we can do better). I will use this.
> On 2 May 2021, at
pproach, so that we can put them next to each other?
>
> -n
>
> --
> Nathaniel J. Smith -- https://vorpus.org
>
_______
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.py
e exceptions?
___
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/archives/list/python-dev@python
posal
> > >now adds another 10 extra lines to jump over :-)
> >
> > If the slice were instead marked with color tagging, as I hope will be
> > possible in IDLE and other IDEs, then no extra lines well be needed
>
> That's great for people using IDLE, but fo
On Tue, 23 Mar 2021 at 21:39, Python Steering Council
wrote:
>
> This isn’t happening because GitHub/Microsoft made a political decision. It’s
> happening because it is incredibly easy to make this move, many projects have
> already done this, and it reflects badly on any projec
Hi,
PEP 234 mention
https://sourceforge.net/p/python/mailman/python-iterators/ but the
project mailing list archives are marked as "hidden".
Looks like projects admin and developers can get the "hidden link", but
I think it would be nice to "unhide" the archives i
print_exception in module traceback:
print_exception(exc, /, value=, tb=,
limit=None, file=None, chain=True)
Is there a convention on how such default sentinel values should appear in
docs?
https://bugs.python.org/issue43024
_______
Python-Dev mailing
27;m with or .
The arg is only there for backwards compatibility now.
___
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 arch
oken)
> '<_UNSET.token: 1>'
>
>
> All of these are in use by some developers, though not necessarily in
> the stdlib. None is perfect, though all are probably good enough.
> Since pickling is likely not relevant in most cases, I'm currently in
> favor of #2 ma
ld be weird at best that the default for a
dataclass field can be any value, except for the builtin Ellipsis value.
Ronald
>
> Cheers,
>
> Luciano
>
> On Thu, May 20, 2021 at 8:35 AM Victor Stinner wrote:
>>
>> IMO you should consider writin
Le 5/11/21 à 8:39 PM, Guido van Rossum a écrit :
> I doubt that anyone has the keys to the python project on sourceforge
> any more... :-( We've abandoned that platform nearly two decades ago.
That's right…
Sourceforge staff mentionned there's the list of current a
Hi,
Le 5/25/21 à 9:18 PM, Brett Cannon a écrit :
> Is there something to do here? The python-iterators mailing list is
> already marked as public.
Looks like Guido is faster than you and set it public already. But looks
like the archives are corrupted or something, it's almost empty
Some bad news about python-iterat...@lists.sourceforge.net, looks like
sourceforge lost a huge part of the mailing list: they have 0 message
before Sep. 2001.
So I think I'll soon drop the link(s) refering to it in the PEPs.
--
[Julien Palard](https://m
.
[1]:
https://web.archive.org/web/*/http://www.geocrawler.com/archives/3/9283/*
--
[Julien Palard](https://mdk.fr)
_______
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/m
give iterators instead of
> iterables as a hint they're not "rewindable" was initially thought
> of and part of the design, or it emerged later.
Then I went yak shaving...
--
[Julien Palard](https://mdk.fr)
_______
Python-Dev maili
Well done Victor!
This stuff is way over my head, but rest assured that humble Python
programmers like me appreciate all the effort put in from guys like you
into improving Python.
Rob Cliffe
On 01/06/2021 23:14, Victor Stinner wrote:
On Fri, May 28, 2021 at 6:40 PM Victor Stinner wrote
ontexts... was
> it maybe a medical context? So "living" would be "unstable" too, as Tim
> suggested.
>
> And since people know what a living document is, a living API wouldn't be
> much of a stretch.
>
> On the other hand, "unstable" carries
y 1, which I think Ethan does.
And the ‘exact’ requirement (that each bit is covered once) surely doesn’t
apply.
It’s more like “full cover by singletons”.
___________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le..
Jun 7, 2021 at 6:36 PM Ethan Furman wrote:
> On 6/6/21 9:14 AM, Irit Katriel via Python-Dev wrote:
> > On 6 Jun 2021, at 16:58, Andrei Kulakov wrote:
>
> >> In Math / CompSci there is a definition that almost exactly matches
> this: Exact Cover -
> >> https://
> On 7 Jun 2021, at 05:05, Inada Naoki wrote:
>
> Hi, folks,
>
> Since Python 3.8, PyArg_Parse*() APIs and Py_BuildValue() APIs emitted
> DeprecationWarning when
> '#' format is used without PY_SSIZE_T_CLEAN defined.
> In Python 3.10, they raise a Runt
> On 9 Jun 2021, at 11:13, Victor Stinner wrote:
>
> On Wed, Jun 9, 2021 at 10:32 AM Ronald Oussoren via Python-Dev
> wrote:
>> Its a bit late to complain (and I’m not affected by this myself), but those
>> functions are part of the stable ABI. The chang
.
> Is it ABI change? I don't think so.
I agree. But its not as easy as “it is not an ABI change because it only
changes functionality of a function”. The interface contract of
Py_CompileString is that it compiles Python code. If the rules for what valid
Python code is change (such as
is still
relevant. If you see "version 3.5" then it makes sense to check on a
current version and either update the issue or close it.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@py
libraries if they don't want to
migrate to the suggested alternatives - the modules are pure python and
anyone can include a copy in their own codebase and continue using it in a
legacy application (or even continue maintaining it if they want).
Barry and I are working on a patch to add deprec
7;))
Traceback (most recent call last):
File "", line 1, in
File "", line 5, in __str__
KeyError: '"a"'
Basically, f-strings rely on eval-like semantics.
Martin
___
Python-Dev mailing list -- python-de
'{d[a]}'
Traceback (most recent call last):
File "", line 1, in
NameError: name 'a' is not defined
Yes, having three different ways of doing string interpolation (not
counting other things you can import, like string.Template) is a bit
confusing.
Mar
Matthew Rahtz via Python-Dev wrote:
> > Hi everyone,
> > We've got to the stage now with PEP 646 that we're feeling pretty happy
> with
> > it. So far though we've mainly been workshopping it in typing-sig, so as
> PEP 1
> > requires we're askin
versions?
Any help appreciated!
--
~Ethan~
[1] https://stackoverflow.com/q/68319071/208880
___
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
anks, PEP updated.
--
~Ethan~
_______
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/archives/list/
this issue: https://github.com/tensorflow/tensorflow/issues/31579).
Variadic generics are among the last few missing pieces to create an
elegant set of type definitions for tensors and shapes.
Best,
Dan Moldovan
Software Engineer, TensorFlow Dev Team
___
P
Team
___
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/archives/list/python-dev@python.org/message/HTCARTYYCHETAMHB6OVRNR5EW5T
you continue to mark my post as
> spammy, when I simply tried to get help! This is unacceptable!
>
Marco thought this was a help-with-python list, and in this light his
reaction sort of makes sense.
The reality, Marco, is that this list is for discussions about python
development, not for se
ect.c was changed to use Py_TRASHCAN_BEGIN / END?
>
We just changed frameobject.c to use the new macros. Can you check?
https://github.com/python/cpython/pull/27683
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an em
Thanks, I've updated the PR. https://github.com/python/cpython/pull/27693
I added migration instructions to the news file (which Pablo can copy into
what's new once it's committed).
Also added a Py_DEPRECATED(3.11) typedef which is used in the macro.
It remains the decide how
you
observed the problem and we fixed things that could have caused it. Please
open a new issue if you still see this bug".
_______
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://m
if I missed a more elegant solution (suggestions welcome),
but if I could write
byte(i)
that would feel more Pythonic to me.
Best wishes
Rob Cliffe
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-d
> On 11 Sep 2021, at 06:57, Ethan Furman wrote:
>
> If the previous output needs to be maintained, for example to ensure
> compatibily between different Python versions, software projects will need to
> create their own enum base class with the appropriate methods overridde
out bytes and
characters being different things.
Can you show examples in existing code of how this would be used? I'm unclear
on how frequently users need to create a single byte from an integer. For me,
it is very rare.
It's probably rare, but recently I was converting from P
ting changing
anything.
-CHB
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R(206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
chris.bar...@noaa.gov
__
On 26/09/2021 05:21, Steven D'Aprano wrote:
[snip]
As for the C-API... Python is 30 years old. Has it ever had a stable
C-API before now? Hasn't it *always* been the case that C packages have
targetted a single version and need to be rebuilt from source on every
release?
No.
The
at the problems are that
>> keep people from targeting the stable ABI (or the various other attempts at
>> standardising extensions over Python versions).
>
> It takes some effort to port old extensions to stable ABI. Several old APIs
> are not supported in stable ABI extensions.
> On 28 Sep 2021, at 10:05, Antoine Pitrou wrote:
>
> On Mon, 27 Sep 2021 10:51:43 -0600
> Eric Snow mailto:ericsnowcurren...@gmail.com>>
> wrote:
>> We've frozen most of the stdlib modules imported during "python -c
>> pass" [1][2], to mak
On 27/09/2021 21:53, Brett Cannon wrote:
On Sun, Sep 26, 2021 at 3:51 AM Phil Thompson via Python-Dev <
python-dev@python.org> wrote:
On 26/09/2021 05:21, Steven D'Aprano wrote:
[snip]
> These are not rhetorical questions, I genuinely do not know. I *think*
> that there
> On 28 Sep 2021, at 10:54, Antoine Pitrou wrote:
>
> On Tue, 28 Sep 2021 10:51:53 +0200
> Ronald Oussoren via Python-Dev wrote:
>>> On 28 Sep 2021, at 10:05, Antoine Pitrou wrote:
>>>
>>> On Mon, 27 Sep 2021 10:51:43 -0600
>>> Eric Sno
change that (e.g., make except* a token), and in any case we need to settle
on a convention that we use in documentation, etc.
It is also not too late to opt for a completely different syntax if a
better one is suggested.
___
Python-Dev mailing list
advantage, as I see it, from a linguistic point of view, is that
> "except in" could be read as "excluding", but, then, so could "except each"
> ("excluding each of these") and "except group" ("excluding this group").
&g
I would be in favor of
that, or something like it.
Or perhaps `except for` ?
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
___
Python-Dev
On 05/10/2021 07:59, Nick Coghlan wrote:
On Tue, 28 Sep 2021, 6:55 am Brett Cannon, wrote:
On Sun, Sep 26, 2021 at 3:51 AM Phil Thompson via Python-Dev <
python-dev@python.org> wrote:
However the stable ABI is still a second class citizen as it is still
not possible (AFAIK) to spe
lass field Final:
a: Final[int] = dataclasses.field(init=False, default=10)
I've opened an issue as well and would greatly appreciate any feedback:
https://bugs.python.org/issue45384
I appreciate your time,
Gregory Beauregard
___
Python-Dev mailing lis
is there a case
for deprecating it?
* There are 46 outstanding issues on the bug tracker. Is the above the
reason for this, I don't know?
--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.
Mark Lawrence
__
0.2 ms" (79% of samples) is less a lie than
> > 26.1 ms (0.2%).
>
> I think I understand the point you are making. I'll have to think about
> it some more to decide if I agree with you.
>
> But either way, I think the work you
On 14/06/2016 16:51, Paul Moore wrote:
On 14 June 2016 at 16:19, Steven D'Aprano wrote:
Why does base64 encoding in Python return bytes?
I seem to recall there was a debate about this around the time of the
Python 3 move. (IIRC, it was related to the fact that there used to be
a b
rely. And if we can't succeed at inlining
then
I suspect the JIT won't end up offering the performance we'd hope for.
_______
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
t to be able to import a lot of code and then
later import+install the JIT and have it benefit the code you already imported?
That’s a pretty interesting idea. We actually load the JIT DLL before we
execute any Python code so currently it wouldn’t have any issues with not
having the full sized
) which was 1.4x
slower. It seems to me we should go with the tuple just because the common
case will be having a single object and it'll be even less common to have these
changing very frequently.
-Original Message-
From: Python-Dev [mailto:python-dev-bounces+dinov=micr
makes sense as
we don't expect these to change very often and we don't expect collisions to
happen very often.
> -Original Message-----
> From: Python-Dev [mailto:python-dev-
> bounces+dinov=microsoft@python.org] On Behalf Of Chris Angelico
> Sent: Tuesday, August 30, 20
wever, can benefit from annotation.
(As to my credentials, which some people seem to crave: I worked on an
earlier version of Google's Python type inferencer (*pytype*) and I'm
currently working on *pykythe *(to be open-sourced), which takes the
function-level information and propagates
nistas, ask not what our language can do for you, ask
what you can do for our language.
Mark Lawrence
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/option
On 25 September 2016 at 21:18, Guido van Rossum wrote:
> Be careful though, comparing these to plain integers should probably
> be allowed,
There's a good reason why it's "opaque" ... why would you want to make it
less opaque?
And I'm curious why Python didn&#x
u would probably benefit from posting to
python-l...@python.org to collect use cases. (We don't "vote" on such
additions. Rather the senior devs consider whether the use cases seem
general enough to justify on-going maintenance costs for new code.)
> I would of course also be
On 02/11/2016 12:09, Terry Reedy wrote:
On 11/2/2016 3:54 AM, Mark Lawrence via Python-Dev wrote:
On 02/11/2016 06:23, Stephen J. Turnbull wrote:
That is correct. This is clearly a feature, and 2.7 currently is
accepting only security-related patches (broadly construed -- a
sufficiently
1301 - 1400 of 1717 matches
Mail list logo
