On 6/24/2014 4:22 AM, Serhiy Storchaka wrote:
> I submitted a number of patches which fixes currently broken
> Unicode-disabled build of Python 2.7 (built with --disable-unicode
> configure option). I suppose this was broken in 2.7 when C
> implementation of the io module was introduced.
It has
Sat Aug 2 12:11:54 CEST 2014, Julian Taylor wrote (in
https://mail.python.org/pipermail/python-dev/2014-August/135623.html ) wrote:
> Andrea Griffini wrote:
>>However sum([[1,2,3],[4],[],[5,6]], []) concatenates the lists.
> hm could this be a pure python case that would profit from
Summary: There needs to be a simple way to opt out at install time.
It would be far better to offer more fine-grained control, but leaving
that better solution to downstream is acceptable.
On 3 September 2014 01:19, Antoine Pitrou wrote:
> RFC 2818 (HTTP over TLS) has the following language
On Mon, Sep 8, 2014 at 3:44 PM, Cory Benfield wrote:
> On 8 September 2014 18:23, Jim J. Jewett wrote:
>> Summary: There needs to be a simple way to opt out at install time.
>> It would be far better to offer more fine-grained control, but leaving
>> that better solu
On Tue, Sep 9, 2014 at 12:11 PM, Christian Heimes wrote:
> On 09.09.2014 05:03, Nick Coghlan wrote:
>>
>> On 9 Sep 2014 10:48, "Jim J. Jewett" > <mailto:jimjjew...@gmail.com>> wrote:
>> From Guido's and your feedback, I think we may need two things
On September 11, 2014, Jeff Allen wrote:
> ... the area of code point
> space used for the smuggling of bytes under PEP-383 is not a
> "Unicode Private Use Area", but a portion of the trailing surrogate
> range. This is a code violation, which I imagine is why
> "surrogateescape" is an error
On Sat Sep 13 00:16:30 CEST 2014, Jeff Allen wrote:
> 1. Java does not really have a Unicode type, therefore not one that
> validates. It has a String type that is a sequence of UTF-16 code units.
> There are some String methods and Character methods that deal with code
> points represented
I have a strong suspicion that I'm missing something; I have been
persuaded both directions too often to believe I have a grip on the
real issue.
So I'm putting out some assumptions; please tell me if I'm wrong, and
maybe make them more explicit in the PEP.
(1) The change will only affect situat
M. Cepl asked:
> What I really don't understand is why this discussion is hg v.
> GitHub, when it should be hg v. git. Particular hosting is
> a secondary issue
I think even the proponents concede that git isn't better enough
to justify a switch in repositories.
They do claim that GitHub (
Brett Cannon wrote:
> 4. Contributor creates account on bugs.python.org and signs the
> [contributor agreement](https://www.python.org/psf/contrib/contrib-form/)
Is there an expiration on such forms? If there doesn't need to be
(and one form is good for multiple tickets), is there an objectio
On Thu, Dec 18, 2014, at 14:13, Maciej Fijalkowski wrote:
> ... http://bugs.python.org/issue23085 ...
> is there any reason any more for libffi being included in CPython?
[And why a fork, instead of just treating it as an external dependency]
Benjamin Peterson responded:
> It has some sort of
On Thu, Dec 18, 2014, at 14:13, Maciej Fijalkowski wrote:
> ... http://bugs.python.org/issue23085 ...
> is there any reason any more for libffi being included in CPython?
Paul Moore wrote:
> Probably the easiest way of moving this forward would be for someone
> to identify the CPython-specific
Barry Warsaw wrote:
>> I don't know exactly what the procedure would be to claim .pyz for *nix,
>> e.g. updating /etc/mime.types, but I think the PEP should at least mention
>> this. I think we want to get as official support for .pyz files on *nix as
>> possible.
Paul Moore wrote:
> I'll add a
On Wed, Feb 18, 2015 at 4:16 PM, Paul Moore wrote:
> On 18 February 2015 at 20:48, Jim J. Jewett wrote:
>> Barry Warsaw wrote:
>>>> I don't know exactly what the procedure would be to claim .pyz for *nix,
>>>> e.g. updating /etc/mime.types,
...
&g
On 24 February 2015 at 18:58, Guido van Rossum wrote:
> The naming of the functions feels inconsistent -- maybe pack(directory,
> target) -> create_archive(directory, archive), and set_interpreter() ->
> copy_archive(archive, new_archive)?
Paul Moore wrote:
> One possible source of confusion w
On Wed, Feb 25, 2015 at 2:33 PM, Paul Moore wrote:
> On 25 February 2015 at 17:06, Paul Moore wrote:
> I've included the resulting API
> documentation below. It looks pretty good to me.
Me too. I have a few nits anyhow.
> .. function:: create_archive(directory, target=None, interpreter=None,
On 10 March 2015 at slightly after midnight. Paul Moore wrote:
> Personally I doubt it would make much difference. If the docs say
> "pygmentize" I'm unlikely to dig around to find that the incantation
> "python -m pygments.somemodule:main" does the same thing using 3 times
> as many characters
On 16 March 2015 Petr Viktorin wrote:
> If PyModuleCreate is not defined, PyModuleExec is expected to operate
> on any Python object for which attributes can be added by PyObject_GetAttr*
> and retrieved by PyObject_SetAttr*.
I assume it is the other way around (add with Set and retrieve with Ge
On Tue Apr 28 23:49:56 CEST 2015, Guido van Rossum quoted PEP 492:
> Rationale and Goals
> ===
>
> Current Python supports implementing coroutines via generators (PEP
> 342), further enhanced by the ``yield from`` syntax introduced in PEP
> 380. This approach has a number of short
On Wed, Apr 29, 2015 at 2:26 PM, Paul Moore wrote:
> On 29 April 2015 at 18:43, Jim J. Jewett wrote:
>> So? PEP 492 never says what coroutines *are* in a way that explains
>> why it matters that they are different from generators.
...
> Looking at the Wikipedia article on
On Wed Apr 29 20:06:23 CEST 2015,Yury Selivanov replied:
>> As best I can guess, the difference seems to be that a "normal"
>> generator is using yield primarily to say:
>> "I'm not done; I have more values when you want them",
>> but an asynchronous (PEP492) coroutine is primarily saying:
On Thu, Apr 30, 2015 at 3:32 PM, Guido van Rossum wrote:
(me:)
>> A badly worded attempt to say
>> Normal generator: yield (as opposed to return) means
>> that the function isn't done, and there may be more
>> things to return later.
>> but an asynchronous (PEP492) coroutine is primarily saying
On Fri, May 1, 2015 at 2:59 PM, Guido van Rossum wrote:
> On Fri, May 1, 2015 at 11:26 AM, Jim J. Jewett wrote:
>>
>> On Thu, Apr 30, 2015 at 3:32 PM, Guido van Rossum
>> wrote:
>>
>> (Guido:)> Actually that's not even wrong. When using generators as
On Fri, May 1, 2015 at 4:10 PM, Guido van Rossum wrote:
> On Fri, May 1, 2015 at 12:48 PM, Jim J. Jewett wrote:
>>
>> If there are more tasks than executors, yield is a way to release your
>> current executor and go to the back of the line. I'm pretty sure I
>&
On Thu Apr 30 21:27:09 CEST 2015, Yury Selivanov replied:
On 2015-04-30 2:41 PM, Jim J. Jewett wrote:
>> Bad phrasing on my part. Is there anything that prevents an
>> asynchronous call (or waiting for one) without the "async with"?
>> If so, I'm missing so
On Sun May 3 08:32:02 CEST 2015, Stefan Behnel wrote:
> Ok, fair enough. So, how would you use this new protocol manually then?
> Say, I already know that I won't need to await the next item that the
> iterator will return. For normal iterators, I could just call next() on it
> and continue the f
On Fri May 1 23:58:26 CEST 2015, Yury Selivanov wrote:
>>> Yes, you can't use 'yield from' in __exit__/__enter__
>>> in current Python.
>> What do you mean by "can't use"?
> It probably executed without errors, but it didn't run the
> generators.
True. But it did return the one created by __
On Tue May 5 18:29:44 CEST 2015, Yury Selivanov posted an updated PEP492.
Where are the following over-simplifications wrong?
(1) The PEP is intended for use (almost exclusively) with
asychronous IO and a scheduler such as the asynchio event loop.
(2) The new syntax is intended to make it eas
On Tue May 5 21:44:26 CEST 2015,Brett Cannon wrote:
> It's not as
> complicated as it seems when you realize there is an event loop driving
> everything (which people have been leaving out of the conversation since it
> doesn't tie into the syntax directly).
Another reason people don't realize i
Tue May 5 21:48:36 CEST 2015, Yury Selivanov wrote:
> As for terminology, I view this discussion differently. It's
> not about the technical details (Python has asymmetric
> coroutines, that's it), but rather on how to disambiguate
> coroutines implemented with generators and yield-from, from
>
(1) I found the following (particularly "bases classes") very confusing:
"""
If an object that is not a class object appears in the bases of a class
definition, then ``__mro_entries__`` is searched on it. If found,
it is called with the original tuple of bases as an argument. The result
of the c
I understand auto-generating the __hash__ (and __eq__) for a frozen
container; that is just convenient.
But why is there any desire to autogenerate a __hash__ for something
that isn't frozen? Like a list or dict, the normal case would be for
it not to have a hash at all, and the author *should* w
On Mon, Feb 19, 2018 at 5:06 PM, Chris Barker - NOAA Federal <
chris.barker at noaa.gov> wrote:
> If I have this right, on the discussion about frozen and hash, a use
> case was brought up for taking a few steps to create an instance (and
> thus wanting it not frozen) and then wanting it hashable.
I think part of the disconnect is that this enhancement could very
easily be abused, and it seems likely that it will be, because the
problems aren't visible while writing the code -- only when reading it
later.
I therefore suggest making it very clear in the PEP -- and probably in
PEP 8 -- how t
Mark Shannon wrote:
> PY2, etc. really need to go.
> Assuming that this code type checks OK:
>
> if typing.PY2:
> type_safe_under_py2_only()
> else:
> type_safe_under_py3_only()
>
> Is the checker supposed to pass this:
>
> if sys.hexversion < 0x0300:
> type_safe_under_py2_
At Thu May 21 22:27:50 CEST 2015, Guido wrote:
> I want to encourage users to think about annotations as types,
> and for most users the distinction between type and class is
> too subtle,
So what is the distinction that you are trying to make?
That a type refers to a variable (name), and a cl
On Sun May 24 12:06:40 CEST 2015, Nick Coghlan wrote:
> On 24 May 2015 at 19:44, Mark Shannon wrote:
>> On 24/05/15 10:35, Nick Coghlan wrote:
>>> If we leave __definition_order__ out for the time being then, for the
>>> vast majority of code, the fact that the ephemeral namespace used to
>>> ev
On Thu Jun 18 20:33:13 CEST 2015, Larry Hastings asked:
> On 06/18/2015 11:27 AM, Terry Reedy wrote:
>> Unicode 8.0 was just released. Can we have unicodedata updated to
>> match in 3.5?
> What does this entail? Data changes, code changes, both?
Note that the unicode 7 changes also need to
On Fri Jun 26 16:51:13 CEST 2015, Paul Sokolovsky wrote:
> So, currently in Python you know if you do:
>socket.write(buf)
> Then you know it will finish without interruptions for entire buffer.
How do you know that?
Are you assuming that socket.write is a builtin, rather than a
python me
PEP 498 is only the latest PEP where part of the concern is fear that
it may encourage certain types of bad code.
Would it be reasonable to ask PEPs to start including a section on any
recommended changes to PEP8? (e.g., "If an embedded expression
doesn't fit on a single line, factor it out to a
(1) Please make it clear within the abstract what counts as a change.
(1a) E.g., a second paragraph such as "Adding or removing a key, or
replacing a value, counts as a change. Modifying an object in place,
or replacing it with itself may not be picked up."
(1b) Is there a way to force a vers
> On Jan 17, 2016, at 11:10, Brett Cannon wrote:
>> While doing a review of http://bugs.python.org/review/26129/
>> ... update PEP 7 to remove the optionality of curly braces
On Mon Jan 18 03:39:42 EST 2016, Andrew Barnert pointed out:
> There are two ways you could do that.
[The one most p
On Sun Mar 20 16:26:03 EDT 2016, Nikolaus Rath wrote:
> Which I believe makes it completely pointless to cite Python at all. As
> far as I can see, nowadays citations are given for two reasons:
> 1. To give the reader a starting point to get more information on a
>topic.
I don't often see
(1) I think the "built-in" should instead be a module-level function
in the pathlib. If you aren't already expecting pathlib paths, then
you're just expecting strings to work anyhow, and a builtin isn't
likely to be helpful.
(2) I prefer that the function be explicit about the fact that it is
d
On Thu Apr 14 11:19:42 EDT 2016, Victor Stinner posted the latest
draft of PEP 509; dict version_tag
(1) Meta Question: If this is really only for CPython, then is
"Standards Track" the right classification?
(2) Why *promise* not to update the version_tag when replacing a
value with itself?
On Fri, Apr 15, 2016 at 4:41 PM, Victor Stinner
wrote:
> 2016-04-15 19:54 GMT+02:00 Jim J. Jewett :
>> (2) Why *promise* not to update the version_tag when replacing a
>> value with itself?
> It's an useful property. For example, let's say that you have a guard
On Fri, Apr 15, 2016 at 7:31 PM, Victor Stinner
wrote:
> .2016-04-15 23:45 GMT+02:00 Jim J. Jewett :
...
>> I just worry that you may end up closing off even better optimizations
>> later, if you make too many promises about exactly how you will do
>> which ones.
>> T
On Sat, Apr 16, 2016 at 5:01 PM, Victor Stinner
wrote:
> * I mentionned that version++ must be atomic, and that in the case of
> CPython, it's done by the GIL
Better; if those methods *already* hold the GIL, it is worth saying
"already", to indicate that the change is not expensive.
> * I remove
(Tue Oct 29 12:37:52 CET 2013) Victor Stinner wrote:
> For consistency, you cannot keep traces when tracing is disabled.
> The free() must be enabled to remove allocated memory blocks, or
> next malloc() may get the same address which would raise an assertion
> error (you cannot have two memory
(Fri Nov 15 16:57:00 CET 2013) Stephen J. Turnbull wrote:
> Serhiy Storchaka wrote:
> > If the transform() method will be added, I prefer to have only
> > one transformation method and specify a direction by the
> > transformation name ("bzip2"/"unbzip2").
Me too. Until I consider specia
> Steven D'Aprano wrote:
>> I think that heuristics to guess the encoding have their role to play,
>> if the caller understands the risks.
Ben Finney wrote:
> In my opinion, content-type guessing heuristics certainly don't belong
> in the standard library.
It would be great if there were never
As best I can tell, some people (apparently including Guido
and PEP author Antoine) are taking some assumptions almost
for granted, while other people (including me, before Nick's
messages) were not assuming them at all.
Since these assumptions (or, possibly, rejections of them?)
are likely to d
>> So when it is time to guess [at the character encoding of a file],
>> a source of good guesses is an important battery to include.
> The barrier for entry to the standard library is higher than mere
> usefulness.
Agreed. But "most programs will need it, and people will either
include (the s
Nick Coghlan wrote:
>> Arbitrary binary data and ASCII compatible binary data are *different
>> things* and the only argument in favour of modelling them with a single
>> type is because Python 2 did it that way.
Greg Ewing replied:
> I would say that ASCII compatible binary data is a
> *sub
Greg Ewing replied:
>> ... ASCII compatible binary data is a
>> *subset* of arbitrary binary data.
I wrote:
> But in terms of explaining the text model, that
> separation is important enough that
>(2) It *may* be worth creating a virtual
> split in the documentation.
(rough ske
Victor Stinner wrote:
>> Will ascii() ever emit an antislash representation?
> Try ascii(chr(0x1f)).
In which version? I get:
ValueError: chr() arg not in range(0x11)
> How do you plan to use this output? Write it into a socket or a file?
> When I debug, I use print & logging w
Yury Selivanov wrote:
> I think the Motivation section is pretty weak.
I have normally wished for this when I was (semi-
interactively) exploring a weakly structured dataset.
Often, I start with a string, split it into something
hopefully like records, and then start applying filters
and tran
Greg Ewing suggested:
>> This version might be more readable:
>>
>> value = lst[2] except "No value" if IndexError
Ethan Furman asked:
> It does read nicely, and is fine for the single, non-nested, case
> (which is probably the vast majority), but how would
> it handle nested exceptions?
The PEP currently says:
> Alternative Proposals
> =
> Discussion on python-ideas brought up the following syntax suggestions::
>value = expr except default if Exception [as e]
This one was rejected because of the out-of-order evaluation.
Note, however, that the (fart
(Thu Mar 6 23:26:47 CET 2014) Chris Angelico responded:
> On Fri, Mar 7, 2014 at 7:29 AM, Jim J. Jewett wrote:
>> [ note that "x if y" already occurs in multiple contexts, and
>> always evaluates y before x. ]
> Yes, but that's still out of order.
Ye
On Wed Mar 5 17:37:12 CET 2014, Victor Stinner wrote:
> Python 3 now stores the traceback object in Exception.__traceback__
> and exceptions can be chained through Exception.__context__. It's
> convenient but it introduced tricky reference cycles if the exception
> object is used out of the ex
On Thu Mar 6 16:52:56 CET 2014, Antoine Pitrou wrote:
> IMO it is absolutely out of question to allow creation of arbitrary
> frames from Python code, because the structure and initialization of
> frames embody too many low-level implementation details.
So?
Does any of that matter until the
n inside a longer line.
(3a) Does the except expression need to be general, or would it work
if it were limited to a subclause of variable assignments?
(3b) What about comprehensions?
On Fri Mar 7 20:54:31 CET 2014, Chris Angelico wrote:
>On Sat, Mar 8, 2014 at 5:58 AM, Jim J. Jewett w
On Fri Mar 7 20:54:31 CET 2014, Chris Angelico wrote:
> On Sat, Mar 8, 2014 at 5:58 AM, Jim J. Jewett wrote:
>> (Thu Mar 6 23:26:47 CET 2014) Chris Angelico responded:
>>> ...[as-capturing is] deferred until there's a non-closure means of
>>> creating a sub-sco
On Mon Mar 10 18:56:17 CET 2014 (and earlier quotes), Maciej Fijalkowski wrote:
Maciej:>> You should not rely on __del__s being called timely one way or
Maciej:>> another. Why would you require this for the program to work
Maciej:>> correctly in the particular example of __traceback__?
To the e
(1) I believe the recent consensus was that the number of comparisons
made in a dict lookup is an implementation detail. (Please correct me
if I am wrong.)
(2) Is "the item will be hashed at least once" a language guarantee?
For small mappings, it might well be more efficient to just store the
(1) Should fixes to a docstring go in with a patch, even if they
aren't related to the changing functionality?
Bytestring compilation has several orthogonal parameters. Most -- but
not all -- are documented in the docstring. (Specifically, there is
no explanation of the rx parameter which acts
On Mon, Apr 28, 2014 at 12:56 PM, Charles-François Natali
wrote:
> Why would the user care if multiprocessing is used behind the scene?
Err ... that was another set of questions that I forgot to ask.
(A) Why bother raising an error if multiprocessing is unavailable?
After all, there is a perfec
Steven D'Aprano wrote:
> (1) I asked if it would be okay for MicroPython to *optionally* use
> nominally Unicode strings limited to ASCII. Pretty much the only
> response to this as been Guido saying "That would be a pretty lousy
> option", and since nobody has really defended the suggestion,
I *hope* this was a typo! If
case Point(x=a, y=b):
assigns to a and b (instead of x and y, as in a normal call), then that is ...
going to be very easy for me to forget, and to miss even when I'm aware of it.
-jJ
___
Python-Dev mailing list -- p
Matching *should* look like instantiation ...
case Point(2, 4)
*should* mean "Does it match the object that Point(2, 4) would create?".
case Point(2, y=4)
is less crucial, because they *could* rewrite the call -- but why should they
have to? Changing from constants, and
case Poin
case mylib.STATUS_OK, >result:
case mylib.STATUS_OK, >>result:
case mylib.STATUS_OK, ->result:
The second problem with those is that ">" has a very strong tie to "greater
than".
I think -> or even >> *might* be enough to overcome that, but I'm not
comfortable.
(The first problem, of c
Nick Coghlan doesn't want to ever be having conversations about why "case
True:" doesn't behave the same way as "case some.attr.referring.to.true:".
Guido thinks that it strange enough that you won't see it. I agree that it is
odd to define a complicated alias for True, but it isn't so odd to h
Not being able to use a particular variable name (such as match or case) in the
limited context of matching is only a minor wart. Unfortunately, _ for
internationalization is already a well-established convention for something
that you might well want to do within each separate case. It isn't
I don't love the way it moves the variable name away from the capture location,
but it does offer a decent solution for anonymous placeholder variables (other
than _ or __), and makes it clear which variables are being bound (only those
in front of an = sign) vs limiting potential matches (anyth
I suppose that does follow from treating _ specially by not binding to it at
all; I just hadn't thought through it. (I think my mental model had it wiping
out the previous binding even if the "new" one wasn't available.) So I would
prefer that this be stated explicitly in the PEP. (And maybe
I think your changed constructor:
class Car:
def __init__(self, manufacturer, variant):
self.brand = manufacturer
self.model = variant
is a particularly good example, and the PEP should specify whether:
Car("Chrysler", "PT Cruiser")
is matched by:
Car(brand="Chrysler
[Steven D'Aprano st...@pearwood.info responding to Paul Sokolovsky] wrote:
> > Let us be clear: failed matches do not affect
> > surrounding
> > namespaces unless you declare capture variables as global or
> > nonglobal. They might affect the current namespace, but not
> > surrounding namespaces.
Could you be more explicit about what is banned by the control-flow exclusion?
I'm assuming that:
class A:
bar=float
if FOO:
bar=int
def a(x:int, y:int)->int # function defined with annotations
inside control flow
return x+y
Larry Hastings wrote:
> The control-flow exclusion is for /module//attribute/ or /class
> attribute/ annotations:
> class C:
> if random.random() > 0.5:
> my_attr:int=3
> else:
> my_attr2:float=3.5
That very example would be helpful in the FAQ, though I understand if you're
conce
Paul Sokolovsky wrote:
> Ok, let's take "module attribute" as an example. Why do you think
> there's anything wrong with this code:
> ==
> import config
> from .types import *
> if config.SUPPORT_BIGINT:
> var: bigint = 1
> else:
> var: int64 = 1
"Wrong" is too strong, but it would be bett
I probably wouldn't think of that on my own, but the need is rare enough that
having the recipe in the documentation (preferably including the docstring)
might be enough. (Or it might not.)
___
Python-Dev mailing list -- python-dev@python.org
To unsubs
I see a bunch of similar -- but not quite the same -- use cases.
I feel like instead of a set, it should be a dict pointing to an object with
attributes that describe the module in various ways (top-level vs subpackage,
installed on this machine or not, test module or not, etc). I'll understa
The last time I noticed this question (probably around python 2.4?), it was
considered a deliberate decision.
There are languages with more open classes, such as (IIRC) Ruby and Smalltalk,
but Python chose to remain somewhat closed, because monkey-patching is
undesirable, and can be a problem f
I just reread PEP 597, then re-reread the Rationale.
The PEP helps when the locale is ASCII or C, but that isn't enforced in actual
files. I am confident that this is a frequent problem for packages downloaded
from mostly-English sites, including many software repositories.
It does not seem to
(1) Is it really a TypeGuard, or more of a TypeAssertion?
(2) Does this push too hard on "annotations only have one meaning"? If it has
to imported from typing, then probably not, but I think that is worth adding to
the PEP.
(3) Why can't the falsey case of an Optional String narrow to a set
If a TypeGuard returns false, does that mean "it doesn't match", or just "I
can't prove it matches, but it still might"? That seems relevant to the else
clause ... and seems to have changed since the last version I looked at.
-jJ
___
Python-Dev mailin
Inada Naoki wrote:
> Default encoding is used for:
> a. Really need to use locale specific encoding
> b. UTF-8 (bug. not work on Windows)
> c. ASCII (not a bug, but slow on Windows)
> I assume most usages are (b) and (c). This PEP can reduce them soon.
Is this just an assumption, based on those
Who will benefit from this new warning?
Is this basically just changing builtins.open by adding:
if encoding is None and sys.flags.encoding_warning: # and not Android and
not -X utf8 ?
warnings.warn(EncodingWarning("Are you sure you want locale instead of
utf-8?"))
Even for the few
(I apologize if my summaries distort what Inada Naoki
explained.)
He said that some people use the default None when they really want
either UTF-8 or ASCII.
My concern is that the warning will be a false alarm if they really do
need whatever locale returns, and that case may still be common. (I
On Thu, Feb 11, 2021 at 7:35 PM Inada Naoki wrote:
> The PEP helps developers living on UTF-8 locale to find missing
> `encoding="utf-8"` bug.
> This type of bug is very common, and many Windows users are suffered
> by the bug when reading JSON, YAML, TOML, Markdown, or any other UTF-8
> files.
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 determ
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 avail
lowing lines to end of Lib\site.py:
_origopen=open
def open(...):
if ...
warnings.warn(...)
_origopen(...)
"
-jJ
On Fri, Feb 12, 2021 at 6:28 PM Inada Naoki wrote:
>
> On Sat, Feb 13, 2021 at 4:53 AM Jim J. Jewett wrote:
> >
> > Offering encoding="lo
Another advantage of annotating the variable is that it moves some stuff out
the signature line.
def is_str_list(val: List[object]) -> TypeGuard[List[str]]:
is probably OK on length, but if there were even a second typed and defaulted
parameter, it would start to get unwieldy. And if the a
Eric Traut wrote:
"""It must be possible to express the type guard within the function signature.
In other words, the implementation should not need to be present. This is
important for compatibility with type stubs and to guarantee consistent
behaviors between type checkers."""
Can type stubs
Looking at the other replies, I'm wondering if you fully understand python's
variant of version numbering.
I suggest we change the announcement template from:
"Python 3.9.2 is the newest major release of the Python programming language,
and it contains many new features and optimizations."
Petr: What about except *(TypeError, ExceptionGroup):?
Irit: Good question. We should block that as well.
But https://www.python.org/dev/peps/pep-0654/#backwards-compatibility
seems to explicitly recommend the very similar:
except (Exception, ExceptionGroup):
__
The "no subclasses" seems pretty severe, particularly if you can't even use
marker attributes because it isn't clear when a different instance of container
ExceptionGroup will be substituted.
The justification for this restriction was that .split() had to be be able to
instantiate ... wouldn't
Please include an example for:
except *ExceptionGroup: pass
I *think* it swallows all exceptions, instead of re-raising.
I *think* it also catches (and then swallows) bare exception that were not
initially part of an ExceptionGroup.
I *think* it catches anything that gets raised, not just su
1 - 100 of 227 matches
Mail list logo
