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 wou
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
> with
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 `type(None)
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 in
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 co
PI"
is, I think, unrealistic puritism, not to mention unfairly disparaging
towards the programmers who write those APIs.
> The problem is, that I never actually thought about his suggested way.
Some people have, and found that it doesn't always simplify the API that
On Thu, Jul 21, 2022 at 3:42 PM Steven Barker wrote:
> So last night I tried activating mailing list mode [...]
>
To follow up on my own post, here's an update. I figured out that I'd done
something incorrectly the first time I tried muting certain categories of
posts on Disc
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 Mon, Jul 18, 2022 at 6:28 AM Petr Viktorin wrote:
> On 16. 07. 22 8:48, Miro Hrončok wrote:
> > On 15. 07. 22 13:18, Petr Viktorin wrote:
> >> - You can use discuss.python.org's “mailing list mode” (which
> >> subscribes you to all new posts), possibly with filtering and/or
> >> categorizing m
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
https
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
> ty
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 a
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 dif
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 stateme
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() a
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] t
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, th
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 mult
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 that
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 didn
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, sigmo
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 prec
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 P
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 par
> It would be nice if someone did some work and collected a list of tutorials
> about type annotations that exist (especially the ones that are discoverable
> with a simple Bing query) and ranked them by quality.
I went with Google rather than Bing but here's what I found:
https://gist.github.c
I've been wondering whether it would make sense to have a function in `inspect`
that returns the signature of a type, rather than the signature of a specific
callable object.
I'm not attached to any name for such a function, two ideas are
`inspect.signature_of` or `inspect.signature_of_type`.
We just merged changes to the PEP with a detailed runtime API specification.
Highlights are that:
- The new type should have an `inspect.Signature`- inspired structured API
- It should have a backward-compatible interface with the `__args__` and
`__params__`
- As with the PEP 604 union syntax, `_
Using an operator is an interesting idea, and we should probably call it out as
an alternative in the PEP.
It's not a substitute for the current PEP from the standpoint of typing-sig for
a few reasons:
(A) We care that the syntax be forward-compatible with supporting named
arguments, as outline
Good catch, thanks Nick!
It's been specified in a linked doc [0] but I forgot to move that into the PEP
itself.
I'll aim to get that done today.
---
[0]
https://docs.google.com/document/d/15nmTDA_39Lo-EULQQwdwYx_Q1IYX4dD5WPnHbFG71Lk/edit
___
Python-Dev
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
t:
def foo(x): f"is this a docstring? x is {x}"
I'm pretty sure f-strings cannot be used as docstrings in other contexts
because of how broken they'd be in functions.
--
Steven Barker
___
Python-Dev mailing list -- python-dev@py
ync callables
will almost never come up.
As a result, we decided to leave it in for now, but would be happy to remove it
if the SC would prefer that.
If there are no other concerns, we'd like to move forward and submit it to the
SC.
Cheers,
Steven
---
[1] PEP 677: https://www.python
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 ha
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 P
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 ac
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
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
> > strengths
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 because
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 stupi
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, Sequen
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 __future
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 prot
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:
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 promis
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 proto
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 Mark
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
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
> ) ->
In the example I was aiming for something easy to understand that produced a
type illustrating potential problems of PEP 677, which is at its worst when
there are callables in both argument and return position. I don't have a great
real-world example of this worst-case, most of what I've seen in
I've been thinking about readability hard because I share many of your concerns
about readability.
I'm starting to think parenthesizing the outside might work much better in
practice:
```
(int, str -> bool)
```
instead of
```
(int, str) -> bool
```
This looks a bit less familiar, but it
- elimi
In most of our discussions of this idea, we've assumed that we'd adopt the same
semantics that callback protocols use.
If we do that, then only `lambda a: 3` will type check. In order to type check
both you'd have to make `a` positional-only:
```
def IntToIntFunc(a: int, /) -> int:
...
```
Thanks for the feedback. I have a few thoughts.
(1) Concerns about complexity of the syntax make sense to me, it's definitely
possible to write confusing types with this syntax. Readability would be a good
reason to reject this idea, but it does cut both ways because `Callable` can be
hard to
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 an
details
and edge cases we need to consider regarding runtime behavior.
Cheers,
Steven Troxler
-
[1] Earlier python-dev thread
https://mail.python.org/archives/list/python-dev@python.org/thread/VBHJOS3LOXGVU6I4FABM6DKHH65GGCUB/
[2] PEP 677: https://www.python.org/dev/peps/pep-0677/
[3] R
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 un
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
> surp
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 ...
> e
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 avo
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 reme
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 is
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 Pat
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 prac
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
}
>>> func.__annotations__['return'] = int
>>> func.__annotations__['arg'] = float
>>> func.__annotations__
{'arg': , 'return': }
There may be scoping issues to be sorted out, but I don't think they are
insurmountable.
--
Steve
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 vulnerabili
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 m
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 stri
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 U
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 strin
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:
https://www.cvedetails.com/
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, mos
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 that
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 is
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'}
Se
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:
> >Wh
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 w
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 interes
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 only
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 sequences
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 ``uni
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 com
1 - 100 of 1900 matches
Mail list logo
