On Thu, Jan 26, 2023 at 08:34:04PM +0100, Thomas Ratzke wrote:
> Hi all,
>
> i would like to suggest the following Python feature. It naturally
> happens that one want's to repeat the current iteration of a for loop
> for example after an error happened.
Can you give an example of when you
On Sun, Dec 04, 2022 at 08:20:56PM +, Barney Gale wrote:
> Oh brilliant. I'll unsubscribe from this list then. It sounds like the only
> people using it will be those folks who think their tooling preferences are
> more important than creating a joined-up Python community; I can survive
>
On Thu, Dec 01, 2022 at 10:18:49PM +, Rob Cliffe via Python-Dev wrote:
> Wild suggestion:
> Make None.__hash__ writable.
> E.g.
> None.__hash__ = lambda : 0 # Currently raises AttributeError:
> 'NoneType' object attribute '__hash__' is read-only
You would have to write to
On Tue, Nov 29, 2022 at 08:51:09PM -, Yoni Lavi wrote:
> It does make your argument invalid though, since it's based on this
> assumption that I was asking for a requirement on iteration order
> (e.g. like dict's iteration order = insertion order guarantee), which
> is not the case.
Yoni,
On Tue, Nov 29, 2022 at 02:07:34AM +, Oscar Benjamin wrote:
> Let's split this into two separate questions:
Let's not. Your first question about non-deterministic set order being
"innately good" is a straw man: as we've already discussed, set order is
not non-deterministic (except in the
On Tue, Nov 29, 2022 at 01:34:54PM +1300, Greg Ewing wrote:
> I got the impression that there were some internal language reasons
> to want stable dicts, e.g. so that the class dict passed to __prepare__
> preserves the order in which names are assigned in the class body. Are
> there any such use
On Mon, Nov 28, 2022 at 11:13:34PM +, Oscar Benjamin wrote:
> On Mon, 28 Nov 2022 at 22:56, Brett Cannon wrote:
> > That's actually by design. Sets are not meant to be deterministic
> > conceptually as they are essentially a bag of stuff. If you want
> > deterministic ordering you should
On Sun, Sep 18, 2022 at 09:43:26PM +0200, Philipp Burch wrote:
> However, I then read the mentioned post of Steve Dower, with the final
> summary:
>
> > So to summarise my core concern - allowing an API designer to "just
> use None" is a cop out, and it lets people write lazy/bad APIs rather
On Thu, Jul 21, 2022 at 07:06:47PM -0400, Edwin Zimmerman wrote:
> Mailing list mode is not what you want. Instead, turn mailing list mode off
> and set your email settings to these:
>
>
>
> You can adjust the categories you receive email notifications for by changing
> your list of watched
On Wed, Jul 20, 2022 at 05:43:26PM -0700, Ethan Furman wrote:
> It works, but I wouldn't say "quite well" -- any thread from discourse is
> one long linear series of replies, and reading them in chronological order
> means jumping around and trying to figure what is a reply to what.
Sometimes,
Thank you to everyone who responded, it is now clear to me that this
genuinely is a feature, not a bug or limitation of the parser or lexer.
And that there is code relying on that behaviour, including in the
stdlib, so we shouldn't change it even if we could.
--
Steve
Now that we have a new parser for CPython, can we fix the old gotcha
that raw strings cannot end in a backslash?
Its an FAQ and has come up again on the bug tracker.
https://docs.python.org/3/faq/design.html#id26
https://github.com/python/cpython/issues/93314
--
Steve
I believe that your example is the same as this recently opened bug
report.
https://github.com/python/cpython/issues/93167
--
Steve
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
On Mon, Apr 25, 2022 at 10:32:15PM -0700, Larry Hastings wrote:
[...]
> Whichever spelling we use here, the key idea is that C is bound to a
> "ForwardClass" object. A "ForwardClass" object is /not/ a class, it's a
> forward declaration of a class. (I suspect ForwardClass is similar to a
>
On Sat, Apr 23, 2022 at 12:46:37AM -0700, Larry Hastings wrote:
> But rather than speculate further, perhaps someone who works on one of
> the static type analysis checkers will join the discussion and render an
> informed opinion about how easy or hard it would be to support "forward
> class"
On Fri, Apr 22, 2022 at 10:09:33PM -0700, Larry Hastings wrote:
[Larry]
> >>To be clear: `forward class` creates the official, actual class object.
> >>Code that wants to take a reference to the class object may take
> >>references
> >>to the `forward class` declared class, and interact with it
On Sat, Apr 23, 2022 at 06:41:23AM -, Mehdi2277 wrote:
> My main question for this approach is how would this work with type
> checkers? Is there any restriction that forward class's continuation
> must appear in same module? If it's allowed that a forward class may
> be continued in a
On Fri, Apr 22, 2022 at 06:13:57PM -0700, Larry Hastings wrote:
> This PEP proposes an additional syntax for declaring a class which splits
> this work across two statements:
> * The first statement is `forward class`, which declares the class and binds
> the class object.
> * The second
On Sun, Apr 17, 2022 at 06:20:53PM +0100, Pablo Galindo Salgado wrote:
> These APIs are inspect.getframeinfo, inspect.getouterframes,
> inspect.getinnerframes, inspect.stack and inspect.trace.
Are you referring to the FrameInfo namedtuple rather than the functions
themselves?
inspect.stack()
On Sun, Apr 17, 2022 at 08:35:06PM +0100, MRAB wrote:
> You could return only the current attributes by default, but the extra
> attributes on demand. (Slightly strange, but backwards-compatible.)
> Slicing could also return what was requested, e.g. t[ : 4] would return
> the first 4, t[ : 5]
On Fri, Apr 08, 2022 at 08:24:40AM +, Malthe wrote:
> But firstly, let me present the idea. It is very simple, that Python
> should have declarative imports,
I'm not sure I understand why you consider this "declarative".
https://en.wikipedia.org/wiki/Declarative_programming
As I see it,
On Mon, Apr 04, 2022 at 09:27:46AM -0700, Coyot Linden (Glenn Glazer) wrote:
> On 4/4/22 09:25, Paul Moore wrote:
> >On Mon, 4 Apr 2022 at 17:22, Coyot Linden (Glenn Glazer)
> > wrote:
> >>>I would welcome a multiline comment format that didn't involve
> >>>docstrings.
> >>Err, sorry, I meant
On Sat, Apr 02, 2022 at 09:28:55AM -0700, Christopher Barker wrote:
> Anyway, it would be nice for someone to take up the mantle of getting an
> immutable Mapping into the stdlib.
Here is a "FrozenMapping" class that could be added to collections. I
have tested it ~~extensively~~ for nearly two
On Sat, Mar 05, 2022 at 04:42:55PM -, Jason Madden wrote:
> zope.interface relies on this behaviour.
The example you give shows that Interface is a class. It merely has a
metaclass which is not `type`. (I presume that is what's going on
behind the scenes.)
I'm asking about the example
On Sat, Mar 05, 2022 at 11:27:44AM +0200, Serhiy Storchaka wrote:
> Currently the class can inherit from arbitrary objects, not only types.
Is that intentionally supported?
I know that metaclasses do not have to be actual classes, they can be
any callable with the correct signature, but I
On Tue, Feb 08, 2022 at 05:48:46PM -0800, Gregory P. Smith wrote:
> On Tue, Feb 8, 2022 at 2:41 PM Steven D'Aprano wrote:
> > If the answer to those questions are Yes, that rules out using Unums,
> > posits, sigmoid numbers etc as the builtin float. (The terminology is a
>
On Mon, Feb 07, 2022 at 06:23:52PM +, Mark Dickinson wrote:
> - Should we require IEEE 754 floating-point for CPython-the-implementation?
> - Should we require IEEE 754 floating-point for Python-the-language?
If the answer to those questions are Yes, that rules out using Unums,
posits,
On Mon, Feb 07, 2022 at 05:35:17PM -0800, Gregory P. Smith wrote:
> CPython: yes. we use a double.
> Python the language: no. (float is single precision on many micropython
> platforms as it saves precious ram and performance, plus microcontroller
> fpu hardware like an M4 is usually single
On Tue, Feb 08, 2022 at 12:44:46PM +, Steve Dower wrote:
> Agreed. CPython should be specific, Python should be as vague as
> possible. Otherwise, we would prevent _by specification_ using Python as
> a scripting language for things where floats may not even be relevant.
I don't think that
On Sun, Jan 30, 2022 at 08:36:43AM -0800, Jelle Zijlstra wrote:
> Agree, the count of 1.6k open PRs is not a good look for new contributors.
How does that compare to other comparable open source projects?
Number of open PRs per KLOC seems like a more useful metric than just
the number of open
On Wed, Jan 26, 2022 at 02:40:32PM -0800, Neil Schemenauer wrote:
> On 2022-01-18 23:14, Gregory P. Smith wrote:
> >
> >Our stdlib unittest already enables warnings by default per
> >https://bugs.python.org/issue10535.
> >
> >Getting the right people to pay attention to them is always the hard
On Thu, Jan 13, 2022 at 04:23:09AM -, Dennis Sweeney wrote:
> Like others expressed, I don't like the idea of the typing and
> non-typing parts of Python separating.
Its a good thing that this PEP doesn't separate the typing and
non-typing world. The arrow syntax will be a plain old Python
On Thu, Jan 13, 2022 at 06:41:14PM +1000, Nick Coghlan wrote:
> If such a protocol were to be proposed, then int.__arrow__ could be defined
> such that "1 -> 100" was equivalent to "range(1, 100)"
Why? What's the benefit? It is slightly shorter, but no more clear than
range. I would never guess
TL;DR: declaration only syntax is a non-starter. Even if we tried to add
specialised syntax that only appears in annotations, it would become a
regular Python expression almost immediately.
On Sun, Jan 09, 2022 at 08:42:14AM -0800, Christopher Barker wrote:
> Is it more clear for readers to
On Sun, Jan 09, 2022 at 08:42:14AM -0800, Christopher Barker wrote:
> Perhaps it's worth remembering that this thread spun off one about adding
> syntax to Python because the current syntax isn't capable of easily
> expressing an important type hinting concept (i.e. Callable).
I shall quote the
On Mon, Jan 10, 2022 at 05:39:42AM +1100, Chris Angelico wrote:
> From my understanding, "x->y" would create a Callable if given two
> *types*, but its meaning if given two other objects is still
> undefined.
The PEP requires parentheses around the argument list, so that would be
a SyntaxError.
On Sat, Jan 08, 2022 at 08:36:57PM -0600, Skip Montanaro wrote:
> >
> > So if you hate type annotations because they are unreadable, then you
> > hate Python because Python is unreadable.
> >
>
> That seems rather harsh. I suspect if those of us who are uncomfortable
> with the typing subsystem
On Sat, Jan 08, 2022 at 06:30:53PM -0800, Ethan Furman wrote:
> On 1/8/22 5:46 PM, Steven D'Aprano wrote:
>
> > [...] if you hate type annotations because they are unreadable, then you
> > hate Python because Python is unreadable.
>
> Not so.
Are you disputing that
On Sun, Jan 09, 2022 at 02:20:45AM +0100, jack.jan...@cwi.nl wrote:
> Barry:
> > The advantage to users of keeping the languages the same is that
> > readers of your code don’t have to learn two disparate syntaxes to
> > make sense of what they’re reading. One of Python’s enduring
> >
On Sun, Jan 09, 2022 at 01:30:33AM +0100, jack.jan...@cwi.nl wrote:
> In the last year I’ve contributed mods to two packages that were
> rejected because I hadn’t provided typing (and black formatting, but
> that’s a different subject). I’ve reluctantly done so. And while I
> *hated* it
On Sat, Jan 08, 2022 at 12:59:38AM +0100, 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 a really stupid
> idea, but let me post it again on the off chance that it isn’t a
On Sat, Jan 08, 2022 at 12:32:35PM +0200, Serhiy Storchaka wrote:
> 08.01.22 01:59, jack.jan...@cwi.nl пише:
> >> If I can make a wild suggestion: why not create a little language for
> >> type specifications?
>
> We need a way to define aliases. For example, write:
>
> Data = Mapping[str,
On Fri, Jan 07, 2022 at 04:27:37PM -0800, Christopher Barker wrote:
> Note that if PEP 563 is ultimately accepted, then Annotations would be
> strings, and type checkers could use any language they wanted.
Annotations still have to be syntactically valid Python expressions.
>>> from
Apologies if this is the wrong place to raise this (where is the right
place?) but over the last four days, I've received ten subscription
notices for python/issues-test-2 on Github.
Is anyone else also getting multiple subscription notices?
--
Steve
I've done some more thinking more about Serhiy's worry about changing a
factory function to a class, and how that would change the meaning of
type-hints. Say:
def spam(x: Eggs, y:Cheese) -> _Aardvark:
# actual factory function implementation
# later, we use it as a function
On Fri, Dec 24, 2021 at 06:24:03PM -, Jim J. Jewett wrote:
> Steven D'Aprano wrote:
> > In comparison, Mark's version:
> > @Callable
> > def IntToIntFunc(a:int)->int:
> > pass
> > # in the type declaration
> > func: IntToI
On Fri, Dec 24, 2021 at 11:53:22AM +0200, Serhiy Storchaka wrote:
> Some library provide function foo() which returns an instance of private
> type _Foo and people start using it as a type hint.
If people want to shoot themselves in the foot, is it our job to stop
them? Typically the only
On Fri, Dec 24, 2021 at 01:54:35PM +1100, Chris Angelico wrote:
> My reading of this is that a function IS the type of a function with
> that signature, just like how None means the type NoneType. Is that
> correct?
That's not the status quo, but I think the idea is that it will be.
Except that
On Fri, Dec 24, 2021 at 01:28:44PM +1100, Steven D'Aprano wrote:
> Honestly, I cannot see a single positive to using `def` statements.
...
> This is not a rhetorical question.
Hmm, I think I may have come up with one.
If we did teach type checkers to use actual functions as prot
On Thu, Dec 23, 2021 at 05:09:18PM -0800, Guido van Rossum wrote:
> > def func(params)
> >
> > makes a Callable type object?
> >
>
> No, no, no. That syntax has already been discredited.
It has? Where? Have I missed something?
This thread is about using that syntax as an alternative to
On Thu, Dec 23, 2021 at 07:04:17PM -, asleep.c...@gmail.com wrote:
> One thing that you must consider is that function prototypes
Just to be clear, by "function prototype", do you mean what PEP 677
calls a Callable Type?
> have a few implications beyond typing but it seems like you're
>
On Thu, Dec 23, 2021 at 02:09:50PM -0800, Guido van Rossum wrote:
> Without decorator too (that was Lukasz’ idea). Why bother with the
> decorator (*if* we were to go there)?
So that
def func(params): pass
creates a function object, and
def func(params)
makes a Callable type object?
On Thu, Dec 23, 2021 at 03:00:03PM -, asleep.c...@gmail.com wrote:
> Mark Shannon initially proposed that functions be used as types and provided
> this example:
>
> @Callable
> def IntToIntFunc(a:int)->int:
> pass
>
> def flat_map(
> l: list[int],
> func: IntToIntFunc
> )
On Fri, Dec 17, 2021 at 11:35:24AM +1300, Greg Ewing wrote:
> On 17/12/21 6:52 am, Eddie Elizondo via Python-Dev wrote:
> >I've just updated the original Immortal Instances PR
>
> Is it just me, or does Immortal Instances sound like a
> video game franchise?
Or a Doctor Who episode. Doctor Who
On Thu, Dec 16, 2021 at 01:46:38PM +0100, Antoine Pitrou wrote:
> If an object is immortal, then its refcount wouldn't change at all.
Ah, that makes sense, thanks for the explanation.
--
Steve
___
Python-Dev mailing list -- python-dev@python.org
To
On Thu, Dec 16, 2021 at 12:23:09PM +0100, Antoine Pitrou wrote:
>
> The "real number of references" would not be known for immortal objects.
Oh that surprises me. How does that work? Does that imply that some code
might not increment the ref count, while other code will?
--
Steve
On Wed, Dec 15, 2021 at 02:57:46PM -0800, Guido van Rossum wrote:
> Another potential issue is that there may be some applications that take
> refcounts at face value (perhaps obtained using sys.getrefcount()). These
> would find that immortal objects have a very large refcount, which might
>
On Tue, Dec 14, 2021 at 11:56:09AM +0100, Yann Droneaud wrote:
> Hi,
>
> I'm not familiar with the Python release process, but looking at the latest
> release
>
> https://www.python.org/downloads/release/python-3101/
>
> we can see MD5 is still used ... which doesn't sound right in 2021 ...
>
On Mon, Dec 13, 2021 at 06:43:27AM -, Vioshim wrote:
> Anyways, at the moment that I write this message in python3.10.1, It
> happens that when making a class with the dataclasses module, this
> class can't actually be used in Multiple inheritance for Enum
> purposes, this is mostly to
On Thu, Dec 09, 2021 at 05:19:00PM +0100, Ronald Oussoren wrote:
> https://mail.python.org/pipermail/python-dev/2015-October/141953.html
> is an old thread about the difference between type(x)/Py_TYPE(x) and
> x.__class__ that contains some insight about this.
Thanks for the link Ronald, I
I'm looking for some guidance on a bug report involving isinstance and
__getattribute__` please.
The issue is that if your class overloads `__getattribute__`, calling
isinstance on an instance will call the overloaded `__getattribute__`
method when looking up `__class__`, potentially causing
On Tue, Nov 30, 2021 at 02:30:18PM +, Paul Moore wrote:
> And to be clear, it's often very non-obvious how to annotate something
> - in https://github.com/pfmoore/editables I basically gave up because
> I couldn't work out how to write a maintainable annotation for an
> argument that is "a
On Tue, Nov 30, 2021 at 09:17:13AM +, Paul Moore wrote:
> Also, related to the question Terry raised, IMO it would be useful to
> have a clear statement on code that *does* use type annotations, but
> violates them at runtime. To be specific, is the following considered
> as an error?
>
>
On Mon, Nov 29, 2021 at 07:56:16PM -0500, Terry Reedy wrote:
> Maybe it should be reiterated with whatever decision comes forth that
>
> >>> def muladd(x, y, z):
> ... return x * (y+z)
> ...
[...]
> and other duck-typed code will always be legal, idiomatic, and even
> expected as good
On Mon, Nov 29, 2021 at 12:32:19PM +, Mark Shannon wrote:
> Hi,
>
> I am surprised by the insistence on this thread for excluding comparisons
> from constant folding.
> Why should we special case comparisons? Am I missing something here?
We[1] are worried that the benefit gained will not be
On Fri, Nov 26, 2021 at 12:15:10AM +0900, Stephen J. Turnbull wrote:
> I will grant that restricting the type of compiled annotations from
> typing.Any to "string serializing an object's AST" could reasonably be
> said to be "going out of your way to break other use cases". You have
> a valid
On Sat, Nov 20, 2021 at 11:46:56PM -0800, Christopher Barker wrote:
> One example is a use case of mine -- I have built a hierarchical object
> system, built on dataclasses, in which the annotation absolutely has to be
> an actual type(class) object. PEP 563 will very much break this use case.
I
On Mon, Nov 15, 2021 at 10:43:12PM +1100, Chris Angelico wrote:
> The problems here are not Python's, they are code reviewers', and that
> means they're really attacks against the code review tools.
I think that's a bit strong. Boucher and Anderson's paper describes
multiple kinds of
On Mon, Nov 15, 2021 at 03:20:26PM +0400, Abdur-Rahmaan Janhangeer wrote:
> Well, it's not so obvious. From Ross Anderson and Nicholas Boucher
> src: https://trojansource.codes/trojan-source.pdf
Thanks for the link. But it discusses a whole range of Unicode attacks,
and the specific attack you
On Mon, Nov 15, 2021 at 12:28:01PM -0500, Terry Reedy wrote:
> On 11/15/2021 5:45 AM, Steven D'Aprano wrote:
>
> >In another thread, Serhiy already suggested we ban invisible control
> >characters (other than whitespace) in comments and strings.
>
> He said in string *l
On Sun, Nov 14, 2021 at 10:12:39PM -0800, Christopher Barker wrote:
> I am, however, surprised and disappointed by the NKFC normalization.
>
> For example, in writing math we often use different scripts to mean
> different things (e.g. TeX's Blackboard Bold). So if I were to use
> some of the
On Mon, Nov 15, 2021 at 12:33:54PM +0400, Abdur-Rahmaan Janhangeer wrote:
> Yet another issue is adding vulnerabilities in plain sight.
> Human code reviewers will see this:
>
> if user.admin == "something":
>
> Static analysers will see
>
> if user.admin == "something":
Okay, you have a
Out of all the approximately thousand bazillion ways to write obfuscated
Python code, which may or may not be malicious, why are Unicode
confusables worth this level of angst and concern?
I looked up "Unicode homoglyph" on CVE, and found a grand total of seven
hits:
On Fri, Nov 12, 2021 at 10:07:13AM -0500, Paul Ganssle wrote:
> I knew about sortedcontainers and I also don't remember ever seeing a
> situation where I needed one or recommended its use.
We have a very odd situation where apparently sortedcontainers is one
of the most well-known, popular,
On Thu, Nov 11, 2021 at 11:01:32AM -0800, Richard Levasseur wrote:
> Should the stdlib have e.g. SortedList? Probably not, because the use cases
> of such data types are too niche to a one-size-fits-all implementation, and
> there are too many implementations with too many of their own settings.
On Wed, Nov 10, 2021 at 05:11:33PM +1100, Chris Angelico wrote:
> Nothing's technically new. You could make an inefficient sorted dict like
> this:
>
> class SortedDict(dict):
> def __iter__(self): return iter(sorted(self.keys()))
You would need more than that. You would want to ensure
On Tue, Nov 09, 2021 at 10:01:35PM -0800, Christopher Barker wrote:
> Maybe a stupid question:
>
> What are use cases for sorted dicts?
>
> I don’t think I’ve ever needed one.
Good question :-)
> Also, I can’t quite tell from the discussion If a “sorted dict” implements
> something new, or
Hi Bob and welcome,
Before we could even consider adding the sortedcontainers library to the
standard library, we would need to hear from the maintainer(s) of the
library that they agree to the move and would be able to continue
maintaining the library under our release schedule and backwards
On Tue, Nov 09, 2021 at 04:23:50PM -0800, Hasan Diwan wrote:
> As of 3.7. dicts are sorted[1], but I'm unsure if the order can be
> overridden.
Dicts are not sorted, they are kept in insertion order.
>>> d = {3: 'a', 4: 'b', 1: 'c', 2: 'd'}
>>> d
{3: 'a', 4: 'b', 1: 'c', 2: 'd'}
By the way, this discussion is probably better suited to the
Python-Ideas mailing list. But since we're here...
On Tue, Nov 09, 2021 at 11:37:40AM +0100, Sebastian Rittau wrote:
> >>To me, the "natural" solution looks like this:
> >>
> >>def foo(x=None, y): ...
[...]
Chris Angelico asked:
>
On Mon, Nov 08, 2021 at 01:43:03PM -0800, Ethan Furman wrote:
> When is an empty container contained by a non-empty container?
[...]
> SomeFlag.nothing in SomeFlag.something <-- ???
I don't think that consistency with other containers is particularly
relevant here. More useful is consistency
On Wed, Nov 03, 2021 at 11:11:00AM +0100, Marc-Andre Lemburg wrote:
> Coming back to the thread topic, many of the Unicode security
> considerations don't apply to non-Unicode encodings, since those
> usually don't support e.g. changing the bidi direction within a
> stream of text or other
On Wed, Nov 03, 2021 at 11:21:53AM +1100, Chris Angelico wrote:
> TBH, I'm not entirely sure how valid it is to talk about *security*
> considerations when we're dealing with Python source code and variable
> confusions, but that's a term that is well understood.
It's not like Unicode is the
On Tue, Nov 02, 2021 at 05:55:55PM +0200, Serhiy Storchaka wrote:
> All control characters except CR, LF, TAB and FF are banned outside
> comments and string literals. I think it is worth to ban them in
> comments and string literals too. In string literals you can use
> backslash-escape
On Wed, Nov 03, 2021 at 03:03:54AM +1100, Chris Angelico wrote:
> On Wed, Nov 3, 2021 at 1:06 AM Petr Viktorin wrote:
> > Let me know if it's clear in the newest version, with this note:
> >
> > > Here, ``encoding: unicode_escape`` in the initial comment is an encoding
> > > declaration. The
On Mon, Nov 01, 2021 at 11:41:06AM -0700, Toshio Kuratomi wrote:
> Unicode specifies the mapping of glyphs to code points. Then a second
> mapping from code points to sequences of bytes is what is actually
> recorded by the computer. The second mapping is what programmers
> using Python will
Thanks for writing this Petr!
A few comments below.
On Mon, Nov 01, 2021 at 01:17:02PM +0100, Petr Viktorin wrote:
> >ASCII-only Considerations
> >-
> >
> >ASCII is a subset of Unicode
> >
> >While issues with the ASCII character set are generally well understood,
>
On Sun, Oct 31, 2021 at 01:32:29PM +1300, Greg Ewing wrote:
> On 31/10/21 5:47 am, Raymond Bisdorff wrote:
> >Should the tuples comparison is in this case, I thought, not be solely
> >based on the first tuple component?
>
> Whether you think it should or shouldn't, the fact is that it's not.
>
I was using Python 3.10 and got this NameError when I mistyped a name:
NameError: name 'KeyboardInterrupted' is not defined. Did you mean:
'KeyboardInterrupt'?
It even works for attribute errors too.
That's fantastic! This is a really amazing useability improvement, thank
you everyone who was
On Sat, Oct 23, 2021 at 09:49:10AM -0400, Larry Hastings wrote:
> It's an debatable point since "from future" behavior is always off by
> default. I'd certainly agree that libraries /should/ support stringized
> annotations by now, considering they were nearly on by default in 3.10.
> But I
On Thu, Oct 21, 2021 at 09:36:20PM -0700, Christopher Barker wrote:
> On Thu, Oct 21, 2021 at 5:24 PM Steven D'Aprano wrote:
>
> > Runtime type checkers already have to deal with forward refs that are
> > strings, as this is legal, and always will be:
> >
> > d
On Thu, Oct 21, 2021 at 04:48:28PM -0400, Larry Hastings wrote:
> In Python, if you evaluate an undefined name, Python raises a
> NameError. This is so consistent I'm willing to call it a "rule".
> Various folks have proposed an exception to this "rule": evaluating an
> undefined name in an
On Thu, Oct 21, 2021 at 10:49:35AM +0200, Baptiste Carvello wrote:
> > Versions of this that rely on catching AttributeError are simply wrong
> > and are an anti-pattern. They catch too much and silently turn
> > errors into silent wrong behaviour.
> >
> > PEP 505 does not fall into that
On Thu, Oct 21, 2021 at 01:46:27PM +1100, Steven D'Aprano wrote:
> On Tue, Oct 19, 2021 at 05:09:42PM -0700, Michael Selik wrote:
> > If the motivation for this operator is chained lookups, how about adding a
> > feature to the operator module, first? It seems natural to add a
&
On Wed, Oct 20, 2021 at 06:17:59PM +0200, Piotr Waszkiewicz wrote:
> Do you think about something along those lines?
> ```
> phone = book.publisher.owner.phone except AttributeError: None
> ```
This is not equivalent to PEP 505's None-aware operators. The semantics
are very different, and it is
On Tue, Oct 19, 2021 at 05:09:42PM -0700, Michael Selik wrote:
> None and its ilk often conflate too many qualities. For example, is it
> missing because it doesn't exist, it never existed, or because we never
> received a value, despite knowing it must exist?
Does it matter if different
Rob Cliffe is having problems posting to the Python-Dev list, so he
posted an alternative suggestion to the Python-Ideas list:
https://mail.python.org/archives/list/python-id...@python.org/message/6KQUQBKFGJSGDNXFZBSM5OXD2ISLIQTT/
Rob's idea is to use "except for ..." with exception groups,
Hello Doug,
On Thu, Oct 14, 2021 at 03:45:07PM -, Doug Swarin wrote:
> I believe strong and valid arguments can be made about the use of None
> being a fundamental flaw in some types of coding
Can you elaborate on that? Obviously it is not always appropriate to use
None, but I've never
On Thu, Oct 14, 2021 at 11:52:11AM +1300, Greg Ewing wrote:
> Scratch that, it seems __trunc__ also returns an int, at least
> for floats. Not sure what the logic behind that is.
I'm not sure about the logic either, but it is documented as returning
an Integral:
"Truncates the Real x to the
On Sun, Oct 10, 2021 at 09:15:30AM +, Patrick Reader wrote:
> - a LOAD_FAST cannot possibly have any side-effects outside the
> interpreter stack [1]
> [1]: global variables are probably supposed to have the same
> guarantee, but in practice this is not the case
I don't think that lookups
1 - 100 of 1505 matches
Mail list logo
