Re: [Python-Dev] Why not support user defined operator overloading ?

Steven D'Aprano wrote: there is no need to define new syntax at runtime. The parser doesn't need to know the operator's action until runtime It does need to know the operator's precedence and associativity, though, which means either declaring it somewhere, or having some kind of fixed rule.

Re: [Python-Dev] summing integer and class

Igor Vasilyev wrote: class A(): def __add__(self, var): print("I'm in A class") return 5 a = A() a+1 1+a Execution: python test.py I'm in A class Traceback (most recent call last): File "../../test.py", line 7, in 1+a TypeError: unsupported operand type(s) for +: 'int

Re: [Python-Dev] Reduce memory footprint of Python

R. David Murray wrote: I can give you one data point: a mobile platform that (currently) uses Python3, and does not use linecache because of how much memory it consumes. Wouldn't a sensible approach be to discard the linecache when you've finished generating a traceback? You're not likely to be

Re: [Python-Dev] PEP 457: Syntax For Positional-Only Parameters

On 10/10/13 09:51, Larry Hastings wrote: Perhaps we could add (egad, no, I can't believe I'm saying this) a new built-in function that tells you whether or not a local variable has been assigned to yet? def range([start,] stop, [step], /): if not bound(start): start = 0

Re: [Python-Dev] PEP 457: Syntax For Positional-Only Parameters

On 10/10/13 11:57, Nick Coghlan wrote: PEP title: Representation of positional-only parameters Something like "Notation for documenting positional-only parameters" would make it even clearer that this is not a proposal for adding to the syntax of the language. -- Greg

Re: [Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore().

Zero Piraeus wrote: I thought the whole point was to replace code that would otherwise contain 'except: pass' with something slightly more concise. Hmmm, that suggests another potential name. with passing_on(OSError): os.remove(somefile) -- Greg __

Re: [Python-Dev] On suppress()'s trail blazing (was Re: cpython: Rename contextlib.ignored() to contextlib.ignore())

Guido van Rossum wrote: yielding inside "with open(file) as f" seems fine, but yielding inside "with lock" is problematic, since the other side might try to acquire the same lock, and deadlock. So maybe the documentation of a context manager should include whether it's safe to yield inside the

Re: [Python-Dev] Smoothing the transition from Python 2 to 3

On Jun 8, 2016 4:04 PM, "Neil Schemenauer" > wrote: > > I've temporarily named it "Pragmatic Python". I'd like a better > name if someone can suggest one. Maybe something like Perverted, > Debauched or Impure Python. Python Two and Three Quarters. -- Greg _

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

Steven D'Aprano wrote: - Linux /dev/urandom doesn't block, but it might return predictable, poor-quality pseudo-random bytes (i.e. a potential exploit); - Other OSes may block for potentially many minutes (i.e. a potential DOS). It's even possible that it could block *forever*. There wa

Re: [Python-Dev] Why does base64 return bytes?

Joao S. O. Bueno wrote: The arguments about compactness and what is most likely to happen next applies (transmission trhough a binary network protocol), I'm not convinced that this is what is most likely to happen next *in a Python program*. How many people implement their own binary network pr

Re: [Python-Dev] Why does base64 return bytes?

R. David Murray wrote: The fundamental purpose of the base64 encoding is to take a series of arbitrary bytes and reversibly turn them into another series of bytes in which the eighth bit is not significant. No, it's not. If that were its only purpose, it would be called base128, and the RFC wou

Re: [Python-Dev] Why does base64 return bytes?

Stephen J. Turnbull wrote: it does refer to *encoded* characters as the output of the encoding process: > The encoding process represents 24-bit groups of input bits > as output strings of 4 encoded characters. The "encoding" being referred to there is the encoding from input bytes

Re: [Python-Dev] Why does base64 return bytes?

Stephen J. Turnbull wrote: The RFC is unclear on this point, but I read it as specifying the ASCII coded character set, not the ASCII repertoire of (abstract) characters. Well, I think you've misread it. Or at least there is a more general reading possible that is entirely consistent with the

Re: [Python-Dev] Why does base64 return bytes?

Simon Cross wrote: If we only support one, I would prefer it to be bytes since (bytes -> bytes -> unicode) seems like less overhead and slightly conceptually clearer than (bytes -> unicode -> bytes), Whereas bytes -> unicode, followed if needed by unicode -> bytes, seems conceptually clearer to

Re: [Python-Dev] Why does base64 return bytes?

Steven D'Aprano wrote: I'm satisfied that the choice made by Python is the right choice, and that it meets the spirit (if, arguably, not the letter) of the RFC. IMO it meets the letter (if you read it a certain way) but *not* the spirit. -- Greg ___

Re: [Python-Dev] PEP 487: Simpler customization of class creation

Nick Coghlan wrote: Something that isn't currently defined in PEP 520 ... is where descriptors implicitly defined via __slots__ will appear relative to other attributes. In the place where the __slots__ attribute appears? -- Greg ___ Python-Dev maili

Re: [Python-Dev] When to use EOFError?

Nikolaus Rath wrote: I think EOFError conveys more information. UnpicklingError can mean a lot of things, EOFError tells you the precise problem: pickle expected more data, but there was nothing left. I think EOFError should be used for EOF between pickles, but UnpicklingError should be used fo

Re: [Python-Dev] What should a good type checker do? (was: Please reject or postpone PEP 526)

Chris Angelico wrote: Forcing people to write 1.0 just to be compatible with 1.5 will cause a lot of annoyance. Indeed, this would be unacceptable IMO. The checker could have a type 'smallint' that it considers promotable to float. But that wouldn't avoid the problem entirely, because e.g. add

Re: [Python-Dev] PEP 467: last round (?)

Ethan Furman wrote: The problem with only having `bchr` is that it doesn't help with `bytearray`; the problem with not having `bchr` is who wants to write `bytes.fromord`? If we called it 'bytes.fnord' (From Numeric Ordinal) people would want to write it just for the fun factor. -- Greg _

Re: [Python-Dev] PEP 525, third round, better finalization

Nick Coghlan wrote: For synchronous code, that's a relatively easy burden to push back onto the programmer - assuming fair thread scheduling, a with statement can ensure reliably ensure prompt resource cleanup. That assurance goes out the window as soon as you explicitly pause code execution ins

Re: [Python-Dev] Please reject or postpone PEP 526

On Sun, Sep 04, 2016 at 12:31:26PM +0100, Mark Shannon wrote: As defined in PEP 526, I think that type annotations become a hindrance to type inference. In Haskell-like languages, type annotations have no ability to influence whether types can be inferred. The compiler infers a type for everyt

Re: [Python-Dev] Do PEP 526 type declarations define the types of variables or not?

Mark Shannon wrote: Unless of course, others may have a different idea of what the "type of a variable" means. To me, it means it means that for all assignments `var = expr` the type of `expr` must be a subtype of the variable, and for all uses of var, the type of the use is the same as the typ

Re: [Python-Dev] Python 3.6 dict becomes compact and gets a private version; and keywords become ordered

MRAB wrote: On 2016-09-13 07:57, Mark Lawrence via Python-Dev wrote: "tables the idea" has the US meaning of close it down, not the UK meaning of open it up? :) A better phrase would've been "shelves the idea". There's even a module in Python called "shelve", which makes it Pythonic. :-)

Re: [Python-Dev] TextIO seek and tell cookies

Ben Leslie wrote: But the idea of transmitting these offsets outside of a running process is not something that I had anticipated. It got me thinking: is there a guarantee that these opaque values returned from tell() is stable across different versions of Python? Are they even guaranteed to wo

Re: [Python-Dev] PyWeakref_GetObject() borrows its reference from... whom?

Larry Hastings wrote: In contrast, the "borrowed" reference returned by PyWeakRef_GetObject() seems to be "borrowed" from some unspecified entity. It's a delocalised quantum reference, borrowing a little bit from all strong references in existence. :-) -- Greg _

Re: [Python-Dev] PyWeakref_GetObject() borrows its reference from... whom?

On Tue, Oct 11, 2016 at 4:03 AM, Paul Moore wrote: If you have an object that forever owns a reference to another object, it's safe to return borrowed references. Even if there are such cases, it seems we're going to have to be a lot more careful about identifying them. It might be safer not

Re: [Python-Dev] PyWeakref_GetObject() borrows its reference from... whom?

Nathaniel Smith wrote: IIRC to handle this gilectomy adds per-object mutexes that you have to hold whenever you're mucking around with that object's internals. What counts as "mucking around with the object's internals", though? If I do the C equivalent of: x = somedict[5] x.dosomething

Re: [Python-Dev] PyWeakref_GetObject() borrows its reference from... whom?

Random832 wrote: Or is this a special kind of lock that you can "assert isn't locked" without locking it for yourself, and INCREF/DECREF does so? I don't think that would work. It might be unlocked at the moment you test it, but someone might lock it between then and the following INCREF/DECREF

Re: [Python-Dev] Optimizing list.sort() by checking type in advance

Elliot Gorokhovsky wrote: I ran the benchmark a couple of times and the numbers seem to exactly line up something like one in five times; perhaps not that crazy considering they're executing nearly the same code? Could this be a result of a time being measured in seconds somewhere and then di

Re: [Python-Dev] re performance

Armin Rigo wrote: The theoretical kind of regexp is about giving a "yes/no" answer, whereas the concrete "re" or "regexp" modules gives a match object, which lets you ask for the subgroups' location, for example. Another issue is that the theoretical engine has no notion of greedy/non-greedy ma

Re: [Python-Dev] Set program name through exec -a or environment variable

Oleg Broytman wrote: On Sat, Mar 18, 2017 at 10:27:58AM -0500, Ryan Gonzalez wrote: exec -a would seem to end up setting argv[0] on the CPython interpreter itself, which I don't think is the desired effect... That's exactly what OP asked -- how to change that? Maybe python itself shoul

Re: [Python-Dev] Micro-optimizations by adding special-case bytecodes?

When testing things like this, as well as testing whether it speeds up your target cases, remember to check that it doesn't slow everything else down due to the increased size of the eval code pushing something out of instruction cache or some such effect. -- Greg

Re: [Python-Dev] Aligning the packaging.python.org theme with the rest of the docs

M.-A. Lemburg wrote: In my role as PSF TM committee member, it's often painful to have to tell community members that they cannot use e.g. really nice looking variants of the Python logo for their projects. Let's not add more pain. But it's always within the PSF's power to give that community m

Re: [Python-Dev] "Micro-optimisations can speed up CPython"

David Wilson wrote: They're referred to as slots throughout typeobject.c That's probably where he got the term from. But it really refers to C-level fields in the type object. Magic methods that don't correspond to C-level type fields are not called slots. -- Greg _

Re: [Python-Dev] "Micro-optimisations can speed up CPython"

Steven D'Aprano wrote: What does "tp" stand for? Type something, I guess. I think it's just short for "type". There's an old tradition in C of giving member names a short prefix reminiscent of the type they belong to. Not sure why, maybe someone thought it helped readability. -- Greg _

Re: [Python-Dev] "Micro-optimisations can speed up CPython"

Serhiy Storchaka wrote: In early ages of C structures didn't create namespaces, and member names were globals. That would certainly explain the origins of it, but I'm pretty sure it wasn't the case by the time Python was invented. So Guido must have liked it for other reasons. -- Greg

Re: [Python-Dev] PEP 7 and braces { .... } on if

Seems like a good idea to tighten it up. If a style guide is going to say "you can either do X or not do X", it might as well not mention X at all. :-) -- Greg ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/p

Re: [Python-Dev] Impact of Namedtuple on startup time

Barry Warsaw wrote: namedtuple is great and clever, but it’s also a bit clunky. It has a weird signature and requires a made up type name. Maybe a metaclass could be used to make something like this possible: class Foo(NamedTuple, fields = 'x,y,z'): ... Then the name is explicit an

Re: [Python-Dev] PEP 550 v3 naming

Yury Selivanov wrote: I can certainly see how "ContextFrame" can be correct if we think about "frame" as a generic term, but in Python, people will inadvertently think about a connection with frame objects/stacks. Calling it ExecutionContextFrame rather than just ContextFrame would make it clea

Re: [Python-Dev] PEP 550 v3

Ethan Furman wrote: So I like ExecutionContext for the stack of WhateverWeCallTheOtherContext contexts. But what do we call it? How about ExecutionContextFrame, by analogy with stack/stack frame. -- Greg ___ Python-Dev mailing list Python-Dev@pytho

Re: [Python-Dev] PEP 550 v3 naming

Guido van Rossum wrote: Perhaps the latter can be shortened to just ContextStack (since the Foo part can probably be guessed from context. :-) -0.9, if I saw something called ContextStack turn up in a traceback I wouldn't necessarily jump to the conclusion that it was a stack of FooContexts ra

Re: [Python-Dev] Scope, not context? (was Re: PEP 550 v3 naming)

Barry Warsaw wrote: This is my problem with using "Context" for this PEP. Although I can't keep up with all names being thrown around, Not sure whether it helps, but a similar concept in some Scheme dialects is called a "fluid binding". e.g. Section 5.4 of http://www.scheme.com/csug8/binding.

Re: [Python-Dev] Scope, not context? (was Re: PEP 550 v3 naming)

Barry Warsaw wrote: I actually think Python’s scoping rules are fairly easy to grasp, The problem is that the word "scope", as generally used in relation to programming languages, has to do with visibility of names. A variable is "in scope" at a particular point in the code if you can acccess i

Re: [Python-Dev] PEP 550 v4

Yury Selivanov wrote: On Mon, Aug 28, 2017 at 1:33 PM, Stefan Krah wrote: [..] * Context managers like decimal contexts, numpy.errstate, and warnings.catch_warnings. The decimal context works like this: 1) There is a default context template (user settable). 2) Whenever the first operati

Re: [Python-Dev] PEP 550 v4

Yury Selivanov wrote: I saying that the following should not work: def nested_gen(): set_some_context() yield def gen(): # some_context is not set yield from nested_gen() # use some_context ??? And I'm saying it *should* work, otherwise it breaks o

Re: [Python-Dev] PEP 550 v4

Yury Selivanov wrote: Consider the following generator: def gen(): with decimal.context(...): yield We don't want gen's context to leak to the outer scope That's understandable, but fixing that problem shouldn't come at the expense of breaking the ability to refacto

Re: [Python-Dev] PEP 550 v4

Yury Selivanov wrote: While we want "yield from" to have semantics close to a function call, That's not what I said! I said that "yield from foo()" should have semantics close to a function call. If you separate the "yield from" from the "foo()", then of course you can get different behaviours.

Re: [Python-Dev] PEP 550 v4

Yury Selivanov wrote: BTW we already have mechanisms to always propagate context to the caller -- just use threading.local() or a global variable. But then you don't have a way to *not* propagate the context change when you don't want to. Here's my suggestion: Make an explicit distinction bet

Re: [Python-Dev] Inplace operations for PyLong objects

Chris Angelico wrote: This particular example is safe, because the arguments get passed individually - so 'args' has one reference, plus there's one more for the actual function call However, that's also true when you use the += operator, so if the optimisation is to trigger at all in any usefu

Re: [Python-Dev] PEP 550 v4

Yury Selivanov wrote: Question: how to write a context manager with contextvar.new? var = new_context_var() class CM: def __enter__(self): var.new(42) with CM(): print(var.get() or 'None') My understanding that the above code will print "None", because "

Re: [Python-Dev] PEP 550 v4

Yury Selivanov wrote: Greg, have you seen this new section: https://www.python.org/dev/peps/pep-0550/#should-yield-from-leak-context-changes That section seems to be addressing the idea of a generator behaving differently depending on whether you use yield-from on it. I never suggested that, a

Re: [Python-Dev] PEP 550 v4

Ivan Levkivskyi wrote: Normal generators fall out from this "scheme", and it looks like their behavior is determined by the fact that coroutines are implemented as generators. This is what I disagree with. Generators don't implement coroutines, they implement *parts* of coroutines. We want "t

Re: [Python-Dev] PEP 550 v4

Nathaniel Smith wrote: Literally the first motivating example at the beginning of the PEP ('def fractions ...') involves only generators, not coroutines, and only works correctly if generators get special handling. (In fact, I'd be curious to see how Greg's {push,pop}_local_storage could handle t

Re: [Python-Dev] PEP 550 v4

Nathaniel Smith wrote: The implementation strategy changed radically between v1 and v2 because of considerations around generator (not coroutine) semantics. I'm not sure what more it can do to dispel these feelings :-). I can't say the changes have dispelled any feelings on my part. The implem

Re: [Python-Dev] PEP 550 v4

Guido van Rossum wrote: This feels like a very abstract argument. I have a feeling that context state propagating out of a call is used relatively rarely -- it must work for cases where you refactor something that changes context inline into a utility function (e.g. decimal.setcontext()), but

Re: [Python-Dev] PEP 550 v4

Yury Selivanov wrote: It would be great if you or Greg could show a couple of real-world examples showing the "issue" (with the current PEP 550 APIs/semantics). Here's one way that refactoring could trip you up. Start with this: async def foo(): calculate_something() #in a corou

Re: [Python-Dev] PEP 550 v4

Guido van Rossum wrote: Yeah, so my claim this is simply a non-problem, and you've pretty much just proved that by failing to come up with pointers to actual code that would suffer from this. Clearly you're not aware of any such code. In response I'd ask Yuri to come up with examples of real c

Re: [Python-Dev] PEP 550 v4

Yury Selivanov wrote: I still think that giving Python programmers one strong rule: "context mutation is always isolated in generators" makes it easier to reason about the EC and write maintainable code. Whereas I think it makes code *harder* to reason about, because to take advantage of it you

Re: [Python-Dev] PEP 550 v4

Yury Selivanov wrote: 1. So essentially this means that we will have one "local context" per context manager storing one value. I can't see that being a major problem. Context vars will (I hope!) be very rare things, and needing to change a bunch of them in one function ought to be rarer still.

[Python-Dev] Re: What is __int__ still useful for?

On 14/10/21 6:10 am, Antoine Pitrou wrote: It seems that __int__ has now become a strict equivalent to __trunc__. Not really -- __int__ is expected to return something of type int, whereas __trunc__ is expected to return the same type as its operand. -- Greg ___

[Python-Dev] Re: What is __int__ still useful for?

On 14/10/21 11:19 am, Greg Ewing wrote: Not really -- __int__ is expected to return something of type int, whereas __trunc__ is expected to return the same type as its operand. Scratch that, it seems __trunc__ also returns an int, at least for floats. Not sure what the logic behind that is

[Python-Dev] Re: The list.sort(reverse=True) method not consistent with description

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. This is documented in Section 5.6 of the Library Reference: "tuples and l

[Python-Dev] Re: containment and the empty container

On 9/11/21 7:29 pm, Ethan Furman wrote: I've had a couple people tell me that they think of flags as sets, and use set theory / set behavior to understand how flags and groups of flags should interact. If you're going to think of flags as sets, then 'i in flags' should be equivalent to '((1 <<

[Python-Dev] Re: The current state of typing PEPs

On 26/11/21 4:15 am, Stephen J. Turnbull wrote: My understanding is that optional, incremental type hints are and have always been considered the primary use case for annotations by the BDFL I'm not sure that's true. The way I remember it, back when annotations were first introduced, the BDFL d

[Python-Dev] Re: PEP 674: Disallow using macros as l-value

On 8/12/21 4:36 am, Antoine Pitrou wrote: Is there a way to emit a compilation warning when those macros are used as l-values? Even if only enabled on some compilers. Maybe the macro could be written so that it expands to something with a cast around it? I think gcc has an option for warning ab

[Python-Dev] Re: "immortal" objects and how they would help per-interpreter GIL

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? -- Greg ___ Python-Dev mailing list -- python-dev@python.org T

[Python-Dev] Re: "immortal" objects and how they would help per-interpreter GIL

On 17/12/21 6:58 pm, Steven D'Aprano wrote: Or a Doctor Who episode. Doctor Who and the Immortal Instances of Doom. Hmmm... and Guido has a time machine... Is it possible he's secretly a Time Lord? -- Greg ___ Python-Dev mailing list -- python-dev@p

[Python-Dev] Re: Suggestion: a little language for type definitions

On 9/01/22 2:46 pm, Steven D'Aprano wrote: if you can read expressions: spam(eggs | cheese, aardvark) then you can read type expressions: Spam[Eggs | Cheese, Aardvark] That's like me saying that I can read Greek just because I know how to pronounce the letters. I do, but that does

[Python-Dev] Re: Increase of Spammy PRs and PR reviews

On 1/02/22 5:47 am, Lrupert via Python-Dev wrote: This gives a bad impression to others about their intentions (constant contribution of trivial / low quality stuff with little-to-no-gain to achieve a higher number of commits, since it is a visible metric). Or they may just feel that it's bet

[Python-Dev] Re: Please update Cython *before* introcuding C API incompatible changes in Python

On 2/02/22 5:42 am, Victor Stinner wrote: There is an on-going effort adding getter and setter functions on two structures which are causing most troubles on Python updates: * PyThreadState: https://bugs.python.org/issue39947 * PyFrameObject: https://bugs.python.org/issue40421 In the case of P

[Python-Dev] Re: Please update Cython *before* introcuding C API incompatible changes in Python

On 2/02/22 8:48 am, Guido van Rossum wrote: It seems to me that a big part of the problem is that Cython feels entitled to use arbitrary CPython internals. I think the reason for this is that Cython is trying to be two things at once: (1) an interface between Python and C, (2) a compiler that t

[Python-Dev] Re: Please update Cython *before* introcuding C API incompatible changes in Python

On 2/02/22 11:53 am, Christopher Barker wrote: As a long time Cython user, but not a Cython developer, I think (2) is the primary purpose, with (1) as a handy side benefit (otherwise we'd just use ctypes, yes?) Personally, no, I would not "just use ctypes". The main reason I created Pyrex was

[Python-Dev] Re: Please update Cython *before* introcuding C API incompatible changes in Python

On 2/02/22 12:32 pm, Christopher Barker wrote: I can make a "thick" high performance wrapper, e.g. if I want to call an expensive C function on each item in a sequence, I can do that in Cython, removing a lot of the overhead of Python. "Not as fast as possible" doesn't necessarily mean *slow

[Python-Dev] Re: Descriptions in unittest and avoiding confusion

On 5/04/22 4:27 am, Coyot Linden (Glenn Glazer) wrote: On 4/4/22 09:25, Paul Moore wrote: I'm confused, what's wrong with """..."""? Triple quoted strings are not exclusively for docstrings... Paul That isn't my reading of PEP 257, I would be happy to be wrong about this. PEP 257 recommends

[Python-Dev] Re: About PEPs being discussed on Discourse

On 8/04/22 12:13 pm, Gregory P. Smith wrote: And for lurkers and subscribers here to enable email notifications for categories of interest over there. Is it possible to participate in a Discourse discussion entirely by email, without having to visit the web site? If not, then if python-dev be

[Python-Dev] Re: Proto-PEP part 1: Forward declaration of classes

On 23/04/22 7:22 pm, Steven D'Aprano wrote: He said that could be used as a very primitive form of separation of interface and implementation, by putting the `forward class` in one module and the `continue` in another. But that only works if there is some way to define the interface of the clas

[Python-Dev] Re: Proto-PEP part 1: Forward declaration of classes

On 23/04/22 10:10 pm, Terry Reedy wrote: 'forward class' for an incomplete class is not at all clear to me.  It is not clear to me which part of speech you intend it to be: noun, verb, adjective, or adverb.  You must have some experience with 'forward' in a different context that makes it clear

[Python-Dev] Re: Proto-PEP part 1: Forward declaration of classes

On 23/04/22 5:44 pm, Chris Angelico wrote: On Sat, 23 Apr 2022 at 15:32, Larry Hastings wrote: Still, it's not the intent of my PEP to condone or facilitate monkeypatching. The only difference is that you call it something different. To me, monkeypatching means modifying the definition of

[Python-Dev] Re: Proto-PEP part 1: Forward declaration of classes

On 23/04/22 6:41 pm, Mehdi2277 wrote: If it's allowed that a forward class may be continued in a different module I do not see how type checker like mypy/pyright could handle that. Classes are generally viewed as closed and fully defined within type checker. The way this kind of thing works in

[Python-Dev] Re: Proto-PEP part 1: Forward declaration of classes

On 26/04/22 12:33 pm, Chris Angelico wrote: That's exactly what I mean though: if the only difference between "monkeypatching" and "not monkeypatching" is whether it was intended, then the only difference is what you call it. No, it's not just a matter of what you call it. If I lose my keys an

[Python-Dev] Re: Proto-PEP part 1: Forward declaration of classes

On 27/04/22 1:04 am, Joao S. O. Bueno wrote: MonkeyPatching in Python is not illegal in this sense. I'm not suggesting it is. You're seizing on the wrong part of the analogy. The point is that what you call something doesn't change its nature. -- Greg __

[Python-Dev] Re: Proto-PEP part 1: Forward declaration of classes

On 27/04/22 2:01 am, Chris Angelico wrote: That would be the case if monkeypatching were illegal. Since it's not, wherein lies the difference? The proposed feature is analogous to forward declaring a struct in C. Would you call what C does monkeypatching? -- Greg __

[Python-Dev] Re: Proto-PEP part 1: Forward declaration of classes

On 27/04/22 11:07 am, Chris Angelico wrote: You're saying that it's somehow different when the original dev intends for it, and that that makes it "not monkeypatching". I dispute that, and I consider that the feature would be helpful whether the original dev meant for it or not. The forward dec

[Python-Dev] Re: Proto-PEP part 1: Forward declaration of classes

On 27/04/22 1:26 pm, Chris Angelico wrote: On Wed, 27 Apr 2022 at 11:18, Greg Ewing wrote: The proposed feature is analogous to forward declaring a struct in C. Would you call what C does monkeypatching? No, because C doesn't have first-class types, much less mutable ones. The purpo

[Python-Dev] Re: PEP 689 – Semi-stable C API tier

On 30/04/22 5:25 am, MRAB wrote: I was going to suggest "metastable". Too late? :-) What, the API is balanced on a knife edge and likely to collapse into something else if you sneeze too hard? -- Greg ___ Python-Dev mailing list -- python-dev@python.

[Python-Dev] Re: How about using modern C++ in development of CPython ?

On 17/10/22 10:13 pm, Denis Kotov wrote: For example, PyObject is much better to implement using C++ class, I used to think this. Python has OO features, C++ has OO features, should be a good match, right? Well, no. Python's OO is very flexible and dynamic, C++'s is very rigid and static. CPyt

[Python-Dev] Re: A proposal to modify `None` so that it hashes to a constant

On 29/11/22 12:51 pm, Guido van Rossum wrote: "Sets weren't meant to be deterministic" sounds like a remnant of the old philosophy, where we said the same about dicts -- until they became deterministic without slowing down, and then everybody loved it. I got the impression that there were some

[Python-Dev] Re: PEP 572 TargetScopeError

Barry Warsaw wrote: Subclassing SyntaxError is then a pragmatic concession to the fact that "SyntaxError" also de facto means "CompilationError” Perhaps there should be a CompilationError tghat SyntaxError and TargetScopeError are subclasses of? -- Greg

[Python-Dev] Re: PEP 572 TargetScopeError

Steven D'Aprano wrote: I find it difficult to imagine a more meaningful distinction than that between syntax and semantics. That may be so, but when specifying a programming language, there is often some flexibility as to whether language rules are considered part of the syntax or the semantics

[Python-Dev] Re: What to do about invalid escape sequences

Rob Cliffe via Python-Dev wrote: Also, the former is simply more *informative* - it tells the reader that baz is expected to be a directory, not a file. On Windows you can usually tell that from the fact that filenames almost always have an extension, and directory names almost never do. --

[Python-Dev] Re: What to do about invalid escape sequences

Glenn Linderman wrote: I wonder how many raw strings actually use the \" escape productively? Maybe that should be deprecated too! ? I can't think of a good and necessary use for it, can anyone? Quite rare, I expect, but it's bound to break someone's code. It might be better to introduce a

[Python-Dev] Re: An f-string issue [Was: Re: Re: What to do about invalid escape sequences]

Glenn Linderman wrote: If that were true, the \n in the above example would already be a newline character, and the parsing of the format expression would not see the backslash. And if it were true, that would actually be far more useful for this situation. But then it would fail for a differ

[Python-Dev] Re: What to do about invalid escape sequences

Eric V. Smith wrote: I'm not in any way serious about this. I just want people to realize how many wacky combinations there would be. It doesn't matter how many combinations there are, as long as multiple prefixes combine in the way you would expect, which they do as far as I can see. -- Greg

[Python-Dev] Re: What to do about invalid escape sequences

If we want a truly raw string format that allows all characters, including any kind of quote, we could take a tip from Fortran: s = 31HThis is a "totally raw" string! -- Greg ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send

[Python-Dev] Re: Deprecating the "u" string literal prefix

On 4/12/19 8:41 am, Christian Heimes wrote: I'm strongly against removing it from Python 3 or even raising a deprecation warning. I agree. I know there is a maintenance cost to keeping things like this around, but in this case it's pretty minor. We've probably already spent more time discussing

[Python-Dev] Re: PEP 611: The one million limit.

On 7/12/19 2:54 am, Rhodri James wrote: You've talked some about not making the 640k mistake I think it's a bit unfair to call it a "mistake". They had a 1MB address space limit to work with, and that was a reasonable place to put the division between RAM and display/IO space. If anything is t

[Python-Dev] Re: Adding a scarier warning to object.__del__?

On 5/01/20 11:41 am, Antoine Pitrou wrote: +1 for pointing to `weakref.finalize` as a better alternative for things that may survive until interpreter shutdown. I'm not sure that weakref.finalize is much better. It can still be called at an arbitrary time from an arbitrary thread with the rest

[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes

On 24/03/20 3:43 pm, Dennis Sweeney wrote: This was an attempt to ensure no one can do funny business with tuple or str subclassing. I was trying to emulate the ``PyTuple_Check`` followed by ``PyTuple_GET_SIZE`` and ``PyTuple_GET_ITEM`` that are done by the C implementation of ``str.startswith()`

[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes

On 25/03/20 9:14 am, 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? No, I don't think so. The purpose of a Python implementation

[Python-Dev] Re: PEP 617: New PEG parser for CPython

On 3/04/20 7:10 am, Guido van Rossum wrote: Since last fall's core sprint in London, Pablo Galindo Salgado, Lysandros Nikolaou and myself have been working on a new parser for CPython. We are now far enough along that we present a PEP we've written: https://www.python.org/dev/peps/pep-0617/

<    1   2   3   4   5   6   7   8   9   10   >