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 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 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 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 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 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 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 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 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 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
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
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
__
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
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,
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 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 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
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 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 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 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 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, 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 Thu, Aug 08, 2019 at 10:00:01AM -0700, Barry Warsaw wrote:
> "The two invalid cases listed above raise TargetScopeError, a new
> subclass of SyntaxError (with the same signature).”
>
> The PEP doesn’t really go into the rationale for why a new exception
> is being defined, and in the issue I
On Fri, Aug 09, 2019 at 01:16:16AM +0100, Rob Cliffe via Python-Dev wrote:
> >The name is perfectly self-descriptive: TargetScopeError means that
> >there's an error with the scope of the target. What else could it mean?
> That's easy for an experienced programmer to say.
Correct. Why should we
On Thu, Aug 08, 2019 at 04:28:28PM -0700, Barry Warsaw wrote:
> On Aug 8, 2019, at 14:58, Steven D'Aprano wrote:
>
> > It's not a syntax error. There's nothing wrong with the syntax per-say:
> > we still have ``target := expression``. There's a problem w
On Wed, Aug 07, 2019 at 07:47:45PM +1000, Chris Angelico wrote:
> On Wed, Aug 7, 2019 at 7:33 PM Steven D'Aprano wrote:
> > What's the rush? Let's be objective here: what benefit are we going to
> > get from this change? Is there anyone hanging out desperately f
On Fri, Aug 09, 2019 at 01:12:59PM -0700, Glenn Linderman wrote:
> The reason I never use raw strings is in the documentation, it is
> because \ still has a special meaning, and the first several times I
> felt the need for raw strings, it was for directory names that wanted to
> end with \ and
I'm not trying to be confrontational, I'm trying to understand your
use-case(s) and see if it would be broken by the planned change to
string escapes.
On Fri, Aug 09, 2019 at 03:18:29PM -0700, Glenn Linderman wrote:
> On 8/9/2019 2:53 PM, Steven D'Aprano wrote:
> >On Fr
On Fri, Aug 09, 2019 at 02:28:13PM -0400, Jonathan Goble wrote:
> I am perplexed at the opinion, seemingly espoused by multiple people
> in this thread, that because a major part of the problem is that the
> warnings were not visible enough, somehow the proposed solution is
> making them not visib
On Sat, Aug 10, 2019 at 12:10:55PM -0700, Glenn Linderman wrote:
> Or invent "really raw" in some spelling, such as rr"c:\directory\"
> or e for exact, or x for exact, or here>"c:\directory\"
>
> And that brings me to the thought that if \e wants to become an
> escape for escape, that maybe
On Wed, Sep 11, 2019 at 09:34:07AM -0400, Daniel Holth wrote:
> I didn't realize you could override __builtins__.str. That's interesting.
Don't touch __builtins__ that's a CPython implementation detail. The
public API is to ``import builtins`` and use that.
This override technique is called mon
I'm going to second Chris' comment about efficiency. The purposes of
this PEP (as I read it) are:
(1) Security (less chance of code intentionally or accidentally
exceeding low-level machine limits that allow a security exploit);
(2) Improved memory use;
(3) And such improved memory use will le
On Wed, Dec 04, 2019 at 01:47:53PM +1100, Chris Angelico wrote:
> Integer sizes are a classic example of this. Is it acceptable to limit
> your integers to 2^16? 2^32? 2^64? Python made the choice to NOT limit
> its integers, and I haven't heard of any non-toy examples where an
> attacker causes y
Although I am cautiously and tentatively in favour of setting limits
if the benefits Mark suggests are correct, I have thought of at least
one case where a million classes may not be enough.
I've seen people write code like this:
for attributes in list_of_attributes:
obj = namedtupl
On Fri, Dec 06, 2019 at 11:10:49AM +, Paul Moore wrote:
[...]
> > They might end up with a million dynamically created classes, each with
> > a single instance, when what they wanted was a single class with a
> > million instances.
>
> But isn't that the point here? A limit would catch this an
On Mon, Dec 09, 2019 at 02:12:37PM -0800, Nathaniel Smith wrote:
> > > On 09/12/2019 2:15 pm, Chris Angelico wrote:
> > You: "We should limit things. Stuff will be faster."
> > Others: "Really? Because bit masking is work. It'll be slower."
I'm not an expert, but the impression I've got from vario
On Sat, Dec 07, 2019 at 07:37:58PM +, Oscar Benjamin wrote:
> I recently hit on a situation that created a one million line code file:
> https://github.com/pytest-dev/pytest/issues/4406#issuecomment-439629715
>
> The original file (which is included in SymPy) has 3000 lines
> averaging 500 ch
On Mon, Dec 09, 2019 at 11:27:56PM -0500, Kyle Stanley wrote:
> I agree, I think that sys would likely be the most reasonable place to read
> these limits from. Also, it seems like a good location for setting of the
> limits, if that becomes an option. This would go along well with the
> existing
On Wed, Dec 11, 2019 at 11:12:59AM +, Mark Shannon wrote:
> Another thing I would like feedback on this:
> My justification for a single limit of one million across the board is
> to ease memorization and learning.
> Is that sufficient justification, or would differing limits be better?
Why
On Wed, Dec 11, 2019 at 10:30:15PM -0500, Richard Damon wrote:
> I will way that in my many years of
> programming experience I can't think of any great cases where a language
> as part of the language definition limited to 'size' of a program to
> good effect,
Good thing that's not what the PEP
The list.sort method is documented to only use less than:
https://docs.python.org/3/library/stdtypes.html#list.sort
but I don't think that is correct, it seems to use greater than if it
exists and less than doesn't. My understanding is that items need to
define one of l.t. or g.t. to make it so
On Sat, Dec 14, 2019 at 02:40:04PM +0200, Serhiy Storchaka wrote:
> 14.12.19 12:45, Steven D'Aprano пише:
> >The list.sort method is documented to only use less than:
> >
> >https://docs.python.org/3/library/stdtypes.html#list.sort
> >
> >but I don't thi
On Sat, Dec 14, 2019 at 04:20:43PM +0200, Serhiy Storchaka wrote:
> 14.12.19 15:29, Steven D'Aprano пише:
> >I might be misinterpreting the evidence, but sorting works on objects
> >that define `__gt__` without `__lt__`.
[...]
> The `<` operator try to use `__lt__`, but
On Sun, Dec 15, 2019 at 09:00:31PM -0800, Larry Hastings wrote:
> I think we should decide the question "should set
> objects maintain insertion order?" literally without any consideration
> about performance implications.
In your opening post:
> I also want FAST lookup because I soemtimes rem
Hi Michael, and welcome!
On Thu, Jan 09, 2020 at 11:37:33AM +0100, Michael wrote:
> I am not questioning the demands of the lint checker - rather - I am
> offering my services (aka time) to work through core to make CPython
> pass it's own (I assume) PEP recommendations or guidelines.
That woul
On Mon, Jan 20, 2020 at 09:59:07PM -0600, Karl O. Pinc wrote:
> It would be nice if the output format for float was documented, to the
> extent this is possible.
I don't think we should make any promises about the repr() of floats.
We've already changed the format at least twice:
- once to swit
On Tue, Jan 21, 2020 at 09:01:29AM -0600, Karl O. Pinc wrote:
> Understood. But you still might want to document, or even define in the
> language, that you're outputting the shortest unambiguous
> representation.
I'm not even sure I would want to do that. That would make it a language
guarante
Hi Zak, and welcome!
This list is for discussing the current and future development of the
CPython interpreter, not a general help-desk for Python beginners.
When you signed up to this email list, the signup page says:
Do not post general Python questions to this list. For help with
Py
On Thu, Jan 23, 2020 at 07:29:58PM -0600, Tim Peters wrote:
> PyObject_RichCompareBool(x, y, op) has a (valuable!) shortcut: if x
> and y are the same object, then equality comparison returns True and
> inequality False. No attempt is made to execute __eq__ or __ne__
> methods in those cases.
>
On Fri, Jan 24, 2020 at 12:36:13PM +0300, Ivan Pozdeev via Python-Dev wrote:
> >I'm tempted to declare this implementation-defined behavior -- *implicit*
> >calls to __eq__ and __ne__ *may* be skipped if both sides are the same
> >object depending on the whim of the implementation.
>
> This can
On Fri, Jan 24, 2020 at 05:45:35AM -0500, Terry Reedy wrote:
> On 1/24/2020 3:36 AM, Victor Stinner wrote:
> >CPython current behavior rely on the fact that it's possible to get
> >the memory address of an object.
>
> No, this behavior relies on the language specification that all objects
> have
On Fri, Jan 24, 2020 at 10:57:11PM +1100, Chris Angelico wrote:
> On Fri, Jan 24, 2020 at 10:44 PM Steven D'Aprano wrote:
> >
> > The only thing I'm unsure of here is whether direct use of the `==` and
> > `!=` operators are included as "implicit calls" t
On Tue, Feb 04, 2020 at 12:33:44PM +1100, Chris Angelico wrote:
[Sebastian Berg]
> > But if `PyObject_RichCompareBool(..., Py_EQ)` is such a fundamental
> > operation (and in a sense it seems to me that it is), is there a point
> > in explicitly defining it?
> >
> > That would mean adding `operato
On Mon, Feb 03, 2020 at 05:26:38PM -0800, Sebastian Berg wrote:
> 1. `==` has of course the logic `NaN == NaN -> False`
> 2. `PyObject_RichCompareBool(a, b, Py_EQ)` was argued to have a useful
>logic of `a is b or a == b`. And I argued that you could define:
>
>def operator.identical(a
Thank you to everyone for your patience while I dragged my feet
responding to this. It's not because of a lack of interest, just a lack
of uninterrupted time to focus on this :-)
I believe that the final sticking points are the behaviour with
subclasses and whether or not the union operator oug
On Sun, Feb 16, 2020 at 02:12:48PM -0800, Guido van Rossum wrote:
> So can we just finish PEP 584 without the .copy() call?
Fine by me.
Thanks to everyone!
--
Steven
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to
On Tue, Feb 18, 2020 at 05:35:38PM -, Brandt Bucher wrote:
> > I am accepting this PEP. Congratulations Steven and Brandt!
>
> Thank you for your guidance, especially the suggestions late last
> year. And thanks Steven for taking me on as a co-author and shaping
> the bulk of the proposal.
On Sat, Mar 21, 2020 at 12:15:21PM -0400, Eric V. Smith wrote:
> On 3/21/2020 11:20 AM, Ned Batchelder wrote:
> >Why be so prescriptive? The semantics of these functions should be
> >about what the resulting string contains. Leave it to implementors to
> >decide when it is OK to return self or
On Fri, Mar 20, 2020 at 06:18:20PM -0700, Nathaniel Smith wrote:
> On Fri, Mar 20, 2020 at 11:54 AM Dennis Sweeney
> wrote:
> > This is a proposal to add two new methods, ``cutprefix`` and
> > ``cutsuffix``, to the APIs of Python's various string objects.
>
> The names should use "start" and "end
On Sun, Mar 22, 2020 at 06:57:52AM +0300, Ivan Pozdeev via Python-Dev wrote:
> Does it need to be separate methods?
Yes.
Overloading a single method to do two dissimilar things is poor design.
> As written in the PEP preface, the very reason for the PEP is that people
> are continuously tryin
On Sun, Mar 22, 2020 at 10:25:28PM -, Dennis Sweeney wrote:
> Changes:
> - More complete Python implementation to match what the type checking in
> the C implementation would be
> - Clarified that returning ``self`` is an optimization
> - Added links to past discussions on Python-
On Tue, Mar 24, 2020 at 08:14:33PM -, Dennis Sweeney wrote:
> I think my confusion is about just how precise this sort of "reference
> implementation" should be. Should it behave with ``str`` and ``tuple``
> subclasses exactly how it would when implemented? If so, I would expect the
> follo
On Tue, Mar 24, 2020 at 08:14:33PM -, Dennis Sweeney wrote:
> I think then maybe it would be preferred to
> use the something like the following in the PEP:
>
> def cutprefix(self, prefix, /):
> if isinstance(prefix, str):
> if self.startswith(prefix):
>
On Tue, Mar 24, 2020 at 04:53:55PM +0100, Walter Dörwald wrote:
> But for `cutprefix()` (or whatever it's going to be called). I'm +1 on
> supporting multiple prefixes. For ambiguous cases, IMHO the most
> straight forward option would be to chop off the first prefix found.
The Zen of Python ha
On Tue, Mar 24, 2020 at 07:14:16PM +0100, Victor Stinner wrote:
> I would prefer to raise ValueError("empty separator") to avoid any
> risk of confusion. I'm not sure that str.cutprefix("") or
> str.cutsuffix("") does make any sense.
They make as much sense as any other null-operation, such as su
On Sat, Mar 28, 2020 at 01:20:11PM +0200, Serhiy Storchaka wrote:
> 2. In many case it is more convenient to have a repr in the form
> Color.RED or even just RED instead of .
+1
--
Steven
___
Python-Dev mailing list -- python-dev@python.org
To unsu
Hi Ilya,
I'm not sure that this mailing list (Python-Dev) is the right place for
this discussion, I think that Python-Ideas (CCed) is the correct place.
For the benefit of Python-Ideas, I have left your entire post below, to
establish context.
[Ilya]
> I needed reversed(enumerate(x: list)) in
On Mon, Apr 06, 2020 at 10:43:11AM -0700, Guido van Rossum wrote:
> I've been toying with the idea of introducing a "match" statement
> similar to Scala's match expression by making "match" a keyword only when
> followed by an expression and a colon.)
Didn't we conclude from `as` that having cont
On Mon, Apr 06, 2020 at 11:54:54AM -0700, Guido van Rossum wrote:
> (In an early version of the PEG parser, all keywords were
> context-sensitive, and there were only very few places in the grammar where
> this required us to insert negative lookaheads to make edge cases parse
> correctly. The res
On Mon, Apr 06, 2020 at 07:03:30PM -0700, Guido van Rossum wrote:
> After 30 years am I not allowed to take new information into account and
> consider a change of heart? :-)
Of course :-)
--
Steven
___
Python-Dev mailing list -- python-dev@python.org
On Sat, Apr 11, 2020 at 03:17:07PM -0700, Mike Miller wrote:
> Python as 𝑣 → 𝑒
> Python ≈ 𝑒
For anyone else who had trouble seeing those glyphs, the ASCII
equivalent is:
Python as v --> e
Python ~= e
with the v and e in italics and the ~= meaning "approximately equal".
--
St
On Wed, May 13, 2020 at 03:04:02PM +0200, Antoine Pitrou wrote:
> On Tue, 12 May 2020 11:36:38 -0700
> Ethan Furman wrote:
> >
> > Also, if a flag is used, won't that slow down every call to zip even when
> > the flag is False?
>
> Why would it? Is that based on a rational analysis of how argu
On Fri, May 15, 2020 at 08:17:12AM +0100, Paul Moore wrote:
> 1. Why do we want to "tempt" people to error when handling mismatched
> lengths? Certainly letting people catch errors easily is worthwhile,
> but rejecting arguments of different lengths may well *not* be an
> error ("be lenient in wha
On Fri, May 15, 2020 at 09:56:03AM -0400, Paul Ganssle wrote:
> I'm on the fence about using a separate function vs. a keyword argument
> (I think there is merit to both), but one thing to note about the
> separate function suggestion is that it makes it easier to write
> backwards compatible code
On Fri, May 29, 2020 at 11:02:56PM +0300, Serhiy Storchaka wrote:
> The default repr of Python object is formatted using the following pattern:
>
> <{typename} object at {address:#x}>
>
> And many custom reprs use similar patterns, but add some additional type
> specific information. The ty
On Mon, Jun 01, 2020 at 09:36:40PM +1000, Nick Coghlan wrote:
> zip() can be used to combine iterables of different lengths, including
> combining finite iterables with infinite iterators. By default, the output
> iterator is implicitly truncated to produce the same number of items as the
> shorte
On Tue, Jun 02, 2020 at 08:52:46PM +1000, Nick Coghlan wrote:
> > Truncate at what?
> >
> > - some maximum length;
> > - some specific element;
> > - at the shortest input.
> >
>
> Given that the only input parameters are the iterables themselves, it's a
> stretch to even consider the first two a
On Fri, Jun 12, 2020 at 09:01:33AM +0100, Rob Cliffe via Python-Dev wrote:
> If I run the following program (using Python 3.8.3 on a Windows 10 laptop):
>
> import sys, time
> for i in range(1,11):
> sys.stdout.write('\r%d' % i)
In Python 2, the 'write()` method returns None, which is suppres
It needs to be pointed out that Thomas Wouters was recently re-elected
to the PSF board. I think we need to know whether Thomas speaks for the
entire PSF board.Giampaolo feared this:
"It's gonna happen again and again, until everybody gets in line, shuts
up or leaves due to exhaustion."
and Tho
On Thu, Jul 02, 2020 at 12:47:07PM -0400, Piper Thunstrom wrote:
> Over the last handful of decades, singular "they" has been explicitly
> taught as inappropriate. My own college writing classes (only 10 years
> ago now) included this specific piece of advice.
>
> In terms of modern English verna
Whenever someone says "Python is the only language..." it really turns
out to be the case. Python is very rarely as unusual as people often
make out.
To my knowledge, there are quite a few other languages that don't have
constants, some of them are even moderately well known languages:
- Mathe
On Thu, Jul 09, 2020 at 01:22:48AM +1000, Steven D'Aprano wrote:
> Whenever someone says "Python is the only language..." it really turns
> out to be the case. Python is very rarely as unusual as people often
> make out.
Gah, embarrasing typo! That was meant to be *rar
On Sat, Jul 18, 2020 at 10:58:17AM +0200, Federico Salerno wrote:
> We don't, after all,
> confuse function calls for references to a function, or vice-versa.
Beginners do. Frequently. Sometimes it is quite a hurdle for them to
learn to write `function()` instead of `function`.
And even experi
On Sat, Jul 18, 2020 at 09:25:45AM -, emmanuel.coir...@caissedesdepots.fr
wrote:
> This approach, for me, seems to come from functionnal languages where
> pattern matching is a thing. The proposed "match" clause tends to
> mimic this approach, and it can be a good thing. But the Python's
>
On Sun, Jul 19, 2020 at 06:38:30PM +0300, Serhiy Storchaka wrote:
> What if use serial numbers to differentiate instances?
I like this idea. It is similar to how Jython and IronPython object IDs
work:
# Jython
>>> id(None)
2
>>> id(len)
3
>>> object()
> I do not
On Sat, Jul 25, 2020 at 12:03:55PM +0300, Serhiy Storchaka wrote:
> 19.07.20 19:33, Steven D'Aprano пише:
> No, I do not propose to change object IDs. I proposed only to use serial
> numbers instead of IDs in reprs of some classes.
Yes, I understood that you were only talking ab
On Sat, Aug 15, 2020 at 12:36:25AM +1000, Chris Angelico wrote:
> Do you have anything new to add to the discussion, or is this 2000
> lines of rehash?
Having a summary of objections/critiques in one place is far better than
expecting people to wade through multiple huge threads.
I've lost coun
On Sat, Aug 15, 2020 at 03:06:46PM -0700, Guido van Rossum wrote:
> But Mark's repo doesn't replace any of the threads -- it just repeats
> Mark's own arguments, which are exclusively focused on the examples in the
> PEP (it's as if Mark read nothing *but* the examples).
Oh, I'm sorry, I based
Hi all,
On the Python-Ideas mailing list, there has been a long debate about
resurrecting PEP 472, "Support for indexing with keyword arguments".
https://www.python.org/dev/peps/pep-0472/
One of the existing authors, Stefano Borini, is interested in updating
the PEP with a new strategy that ha
Okay, thanks everyone who answered.
In hindsight you are all correct, writing a new PEP is the best solution
and I was being over-optimistic (and a little lazy) to think otherwise.
I think that, technically, I still have core dev permissions, even
though I haven't used them for quite some time.
There's still a lot of community angst over the possibility that
some hypothetical Python 4 will be like the 2/3 transition. Some people
even imagine that the version after 3.9 could be that transition.
I know we're not responsible for the ravings of people on social media,
but do you think we
Why does `object` define rich comparison dunders `__lt__` etc?
As far as I can tell, `object.__lt__` etc always return NotImplemented.
Merely inheriting from object isn't enough to have comparisons work. So
why do they exist at all? Other "do nothing" dunders such as `__add__`
aren't defined.
On Tue, Sep 22, 2020 at 02:13:46PM +0300, Serhiy Storchaka wrote:
> 22.09.20 12:48, Steven D'Aprano пише:
> > Why does `object` define rich comparison dunders `__lt__` etc?
> Because object.__eq__ and object.__ne__ exist. If you define slot
> tp_richcompare in C, it is exposed
On Sat, Oct 03, 2020 at 11:41:16AM +0300, Serhiy Storchaka wrote:
> issubclass() accept types (extension types and new-style classes),
> classic classes and arbitrary objects with the __bases__ attribute as
> its arguments.
I didn't think classic classes were still possible in Python 3. How do
yo
On Tue, Oct 13, 2020 at 11:17:33AM +0100, Steve Holden wrote:
> Full marks to the SC for transparency. That's a healthy sign that the
> community acknowledges its disciplinary processes must also be open to
> scrutiny, and rather better than dealing with matters in a Star Council.
The SC didn't sa
Perhaps this is a silly suggestion, but could we offer this as an
external function in the stdlib rather than a string method?
Leave it up to the user to decide whether or not their data best suits
the find method or the new search function. It sounds like we can offer
some rough heuristics, bu
Guido van Rossum wrote:
On Thu, Feb 19, 2009 at 8:38 PM, Brett Cannon wrote:
On Thu, Feb 19, 2009 at 19:41, Benjamin Peterson
wrote:
As we prepare to merge the io-c branch, the question has come up [1]
about the original Python implementation. Should it just be deleted in
favor C version? The
Greg Ewing wrote:
Instead of defining things directly in foo.py, maybe it
should do
try:
from cFoo import *
except ImportError:
from pyFoo import *
Then the fast path will be taken if cFoo is available,
and you can directly import cFoo or pyFoo if you want.
For what it's worth, I
On Wed, 4 Mar 2009 05:23:33 pm Glenn Linderman wrote:
> The problem with the ordereddict/OrderedDict/odict is that there
> are way too many possible orderings, and without being more
> specific (InsertionSequenceOrderPreservingDictionary) people are
> doing to think "sort" when they hear "ordered".
901 - 1000 of 1539 matches
Mail list logo
