[Python-ideas] Re: Operator as first class citizens -- like in scala -- or yet another new operator?

On Wed, 5 Jun 2019 at 09:06, Yanghao Hua wrote: > With my very limited understanding of cpython internals (at least when > I implement <==) it seems cpython is searching for an operator and > then translates it into a method call on the objects Not really. The valid operators are hard coded into

[Python-ideas] Re: python-ideas is now running on Mailman 3

On Wed, 5 Jun 2019 at 20:05, Pradyun Gedam wrote: > > On Wed, 5 Jun 2019 at 10:52 PM, Brett Cannon wrote: >> >> https://mail.python.org/mailman3/lists/python-ideas.python.org/ >> ___ >> Python-ideas mailing list -- python-ideas@python.org >> To

Re: [Python-ideas] Break multiple loop levels

On Sat, 11 May 2019 at 18:22, haael wrote: > Breaking out from many loops at once is a common practice Do you have evidence for this? In my experience, it's very rare (although I concede it would be *occasionally* convenient). In most cases where I'd consider breaking out of multiple levels of

[Python-ideas] Re: Coding using Unicode

On Mon, 15 Jul 2019 at 14:33, Dan Sommers <2qdxy4rzwzuui...@potatochowder.com> wrote: > > On 7/15/19 8:54 AM, Steven D'Aprano wrote: > >  = .(, ) > > I call foul. At least tentatively. For the moment. That was a demo (he used private area characters to ensure

[Python-ideas] Re: JSON encoder protocol

On Sat, 17 Aug 2019 at 08:28, Andrew Barnert via Python-ideas wrote: > def jsonize_my_tree(obj): > if isinstance(obj, MyTreeNode): > return [obj.data(), *map(jsonize_my_tree, obj.children())] > raise TypeError() > > myjson =

[Python-ideas] Re: adding support for a "raw output" in JSON serializer

On Sat, 10 Aug 2019 at 01:17, Greg Ewing wrote: > > Paul Moore wrote: > > So you're proposing a change to the Python > > language stdlib implementation of that translation. Fine. But you have > > yet to provide a justification for such a change, > > I think it c

[Python-ideas] Re: adding support for a "raw output" in JSON serializer

On Tue, 13 Aug 2019 at 10:29, Richard Musil wrote: > > My goal is, as already mentioned: > > To extend JSON encoder to support custom type to serialize into "JSON real > number" (changed "fractional" to "real" to be aligned to Python source > internal comment). > > This includes support for

[Python-ideas] Re: adding support for a "raw output" in JSON serializer

On Tue, 13 Aug 2019 at 11:40, Richard Musil wrote: > > But my proposal is not more complex. Implementing support for Decimal > requires exactly the same steps as implementing the support for custom type. > > 1) One has to recognize the type in the input data, How do you recognise the type? For

[Python-ideas] Re: [Distutils] Re: Linux binary wheels?

On Tue, 20 Aug 2019 at 14:50, Brian Skinn wrote: > I wonder if there's an OS dependence here, though -- I'm almost certain I've > had to use `--only-binary` in the past, to avoid pip on my Windows machines > trying to download and build sdists, even when wheels were available. Pip prefers

[Python-ideas] Re: adding support for a "raw output" in JSON serializer

On Tue, 27 Aug 2019 at 10:22, Richard Musil wrote: > > On Tue, Aug 27, 2019 at 10:48 AM Antoine Pitrou wrote: >> >> On Sun, 11 Aug 2019 20:09:41 -0400 >> David Shawley >> wrote: >> > On Aug 8, 2019, at 3:55 PM, Chris Angelico wrote: >> > >> > I proposed something similar about a year ago [1].

[Python-ideas] Re: Custom string prefixes

On Wed, 28 Aug 2019 at 05:04, Andrew Barnert via Python-ideas wrote: > What matters here is not whether things like the OP’s czt'abc' or my 1.23f or > 1.23d are literals to the compiler, but whether they’re readable ways to > enter constant values to the human reader. > > If so, they’re useful.

[Python-ideas] Re: Custom string prefixes

On Thu, 29 Aug 2019 at 22:12, Andrew Barnert via Python-ideas wrote: > As I’ve said before, I believe that anything that doesn’t have a builtin type > does not deserve builtin syntax. And I don’t understand why that isn’t a > near-ubiquitous viewpoint. But it’s not just you; at least three

[Python-ideas] Re: Add a `dig` method to dictionaries supporting the retrieval of nested keys

On Tue, 3 Sep 2019 at 13:38, None via Python-ideas wrote: > I really believe that a nested key retrieval mechanism should be a > first-class offering of the standard library. It is extremely common in the > Python ecosystem to find developers working with data sets comprised of > nested data

[Python-ideas] Re: Custom string prefixes

On Thu, 29 Aug 2019 at 01:18, Andrew Barnert wrote: > > Also, it's worth noting that the benefits of *user-defined* literals > > are *not* the same as the benefits of things like 0.2f, or 3.14d, or > > even re/^hello.*/. Those things may well be useful. But the benefit > > you gain from

[Python-ideas] Re: Custom string prefixes

On Wed, 28 Aug 2019 at 13:15, Anders Hovmöller wrote: > > > On 28 Aug 2019, at 14:09, Piotr Duda wrote: > > There is much simpler solution, just make `abc"whatever"` synatctic > > sugar for `string_literal_abc(r"whatever", closure)` where closure is > > object that allow read only access to

[Python-ideas] Re: Custom string prefixes

On Wed, 28 Aug 2019 at 13:49, Rhodri James wrote: > OK, I'll bite: how? If you were using "thing.o" I would believe you > were doing something unhelpful with properties, but just "o"? Presumably Unicode variables with confusable characters? Paul ___

[Python-ideas] Re: Custom string prefixes

On Wed, 28 Aug 2019 at 15:55, Mike Miller wrote: > > > On 2019-08-28 01:05, Paul Moore wrote: > > However, I know of almost no examples of other languages that have > > added*user-definable* literal types (with the notable exception of > > Believe there is such a f

[Python-ideas] Re: Custom string prefixes

On Thu, 29 Aug 2019 at 14:21, Andrew Barnert wrote: > You can’t avoid tradeoffs by trying to come up with a rule that makes > language decisions automatically. (If you could, why would this list even > exist?) The closest thing you can get to that is the vague and > self-contradictory and

[Python-ideas] Re: Custom string prefixes

On Thu, 29 Aug 2019 at 15:54, Steven D'Aprano wrote: > Let me suggest some design principles that should hold for languages > with more-or-less "conventional" syntax. Languages like APL or Forth > excluded. This will degenerate into nitpicking very fast, so let me just say that I understand the

[Python-ideas] Re: Conditional dict declarations

On Thu, 5 Sep 2019 at 11:19, wrote: > I find a common requirement I have is to include one or more entries in a > dict only if some condition is met. Currently, the usual way of doing that is > to add one or more if statements. > > Simple (but hopefully relatable-to-real-world-code) example.

[Python-ideas] Re: Automatic translation of Python to assembly language

On Sun, 8 Sep 2019 at 18:14, Mark @pysoniq wrote: > Pythran is "for a subset of the Python language, with a focus on scientific > computing." PysoniQ is not a subset of the Python language. So, to confirm, your product runs the full Python test suite without any errors, and can run the

[Python-ideas] Re: Automatic translation of Python to assembly language

On Sun, 8 Sep 2019 at 20:05, Mark @pysoniq wrote: > > Paul, > > We are just going into beta, so we are not yet in a position to run the tests > you mentioned. When we go to release 1.0, we will be able to do that. Your claims are (currently) inaccurate, then. I suggest that you avoid making

[Python-ideas] Re: for ... except, with ... except

On Tue, 30 Jul 2019 at 04:00, Ethan Furman wrote: > If this "with...except" leads to more robust code then I think many would > like to use it, but not if it's confusing as that would lead to less robust > code. For me, "it's for robust code" is sufficient hint that I now remember what it does

[Python-ideas] Re: PEP's shouldn't require a sponsor

On Sat, 27 Jul 2019 at 03:51, Kyle Stanley wrote: > > Eric V. Smith wrote: > > In addition, I find it hard to believe someone couldn't find a sponsor > > for a well-written PEP. I'm happy to sponsor such a PEP, even if I think > > it will be rejected. Rejected PEPs serve a useful purpose, too, if

[Python-ideas] Re: adding support for a "raw output" in JSON serializer

OK, going back to your original question: On Thu, 8 Aug 2019 at 11:24, Richard Musil wrote: > If I use Decimal, the value is preserved, but there seems to be no way to > "serialize it back". Writing a custom serializer: > > class DecimalEncoder(json.JSONEncoder): > def default(self, o): >

[Python-ideas] Re: adding support for a "raw output" in JSON serializer

On Thu, 8 Aug 2019 at 22:31, Richard Musil wrote: > > I have not asked for means to serialize invalid JSON objects. Yes, with the > "raw" output, you can create invalid JSON, but it does not mean you have to. True. But my point was simply that the json module appears to be designed in a way

[Python-ideas] Re: adding support for a "raw output" in JSON serializer

On Fri, 9 Aug 2019 at 15:20, Richard Musil wrote: > > JSON objects are specified by their textual representation (json.org). > Choosing some binary representation for them (so they can be processed > efficinetly) which does not preserve their value is the problem of the > underlying binary

[Python-ideas] Re: Universal parsing library in the stdlib to alleviate security issues

On Thu, 25 Jul 2019 at 02:16, Nam Nguyen wrote: > Back to my original requests to the list: 1) Whether we want to have a > (possibly private) parsing library in the stdlib In the abstract, no. Propose a specific library, and that answer would change to "maybe". > and 2) What features it should

[Python-ideas] Re: Universal parsing library in the stdlib to alleviate security issues

On Thu, 25 Jul 2019 at 15:53, Nam Nguyen wrote: >> You need to start by getting agreement on the premise that adding a >> newly-written parser to the stdlib is a good idea. And so far your >> *only* argument seems to be that "it will avoid a class of security >> bugs" which I find extremely

[Python-ideas] Re: For-expression/throwaway comprehension

On Fri, 26 Jul 2019 at 13:55, Eli Berkowitz wrote: > Say you have a list and you want to perform some operation on each item in > the list - but you don't need to store the result in a list. > > There are three simple ways of doing this, at least as far as I know: > ([print(item)] could be any

[Python-ideas] Re: Add Subscriptable ABC

On Mon, 30 Sep 2019 at 10:02, Stephen J. Turnbull wrote: > > Steven D'Aprano writes: > > On Sun, Sep 29, 2019 at 11:27:32AM +0100, Oscar Benjamin wrote: > > > > > That's the point that I would make as well. What can you do with an > > > object that is only known to be Subscriptable? > > > >

[Python-ideas] Re: Add «iterate non-blocking» wrapper to prevent blocking loop too long

On Fri, 14 Jun 2019 at 11:38, Nikita Melentev wrote: > > **Sorry, did not know markdown is supported** Oh cool! It's not "supported" in the sense that this is a mailing list, and whether your client renders markdown is client-dependent (mine doesn't for example). But it looks like Mailman3 does,

[Python-ideas] Re: Suggestion for behaviour change import mechanics

On Tue, 29 Oct 2019 at 22:42, Steven D'Aprano wrote: > I expect that with a bit more thought I could come up with some more > scenarios where the behaviour of Python programs could change in very > surprising ways. If you add a module with the same name as a stdlib module to sys.path, current

[Python-ideas] Re: Suggestion for behaviour change import mechanics

On Wed, 30 Oct 2019 at 08:32, Steven D'Aprano wrote: > > On Wed, Oct 30, 2019 at 08:12:12AM +, Paul Moore wrote: > > > > If you add a module with the same name as a stdlib module to sys.path, > > current semantics are that the stdlib wins. > > I don't think

[Python-ideas] Re: Suggestion for behaviour change import mechanics

On Wed, 30 Oct 2019 at 18:45, Brendan Barnwell wrote: > There's nothing new about that either, though. Any imported module > can > already monkeypatch a stdlib module to add such typo-names and map them > to malicious functions. lol, and that's why I'd never make a good security

[Python-ideas] Re: Using 'with' with extra brackets for nicer indentation

On Thu, 14 Nov 2019 at 16:42, Random832 wrote: > So, uh... what if we didn't need backslashes for statements that begin with a > keyword and end with a colon? There's no syntactic ambiguity there, right? > Honestly, adding this would make me less annoyed with the error I get when I > forget

[Python-ideas] Re: Tuple Comprehension

On Mon, 18 Nov 2019 at 03:57, Daniel Zeng wrote: > > Syntax for tuple comprehension, something like: > (i, for i in range(10)) > > This shouldn't result in ambiguity, since generators need to be in > parentheses anyway: > (i, for i in range(10)) vs (1, (i for i in range(10))) I'm going to

[Python-ideas] Re: Using 'with' with extra brackets for nicer indentation

On Sun, 17 Nov 2019 at 19:18, Oscar Benjamin wrote: > That might be useful but it doesn't solve the problem from the > perspective of someone writing context manager utilities like nested > because it still leaves a trap for anyone who uses open with those > utilities. > > Also I don't know of

[Python-ideas] Re: Using 'with' with extra brackets for nicer indentation

On Mon, 18 Nov 2019 at 11:12, Oscar Benjamin wrote: > I am proposing the root of the problem here is the fact that open > acquires its resource (the opened file descriptor) before __enter__ is > called. This is what I mean by a context manager that "misbehaves". If > there was a requirement on

[Python-ideas] Re: Using 'with' with extra brackets for nicer indentation

On Mon, 18 Nov 2019 at 17:17, Oscar Benjamin wrote: > The problem with a misbehaving context manager is that it creates a > future need to call __exit__ before it has been passed to a with > statement or any other construct that can guarantee to do that. You seem to be focusing purely on the

[Python-ideas] Re: Python should take a lesson from APL: Walrus operator not needed

On Thu, 7 Nov 2019 at 00:16, Martin Euredjian via Python-ideas wrote: > Sorry, notation is far more powerful. As I said in one of my other notes, > people who have not had the unique experience of using something like APL for > non-trivial development work simply don't get it. Was your use of

[Python-ideas] Re: Python should take a lesson from APL: Walrus operator not needed

On Thu, 7 Nov 2019 at 18:59, Chris Angelico wrote: > > On Fri, Nov 8, 2019 at 5:40 AM Martin Euredjian via Python-ideas > wrote: > > > > > Was your use of APL on a machine with a dedicated APL keyboard? > > > > I've done both. In the early '80's it was not uncommon to find terminals > > with

[Python-ideas] Re: Using 'with' with extra brackets for nicer indentation

On Mon, 18 Nov 2019 at 18:34, Oscar Benjamin wrote: > > On Mon, 18 Nov 2019 at 17:46, Paul Moore wrote: > > What about > > > > f = open(filename) > > header = f.readline() > > with f: > > # use f > > I would naturally rewrite th

[Python-ideas] Re: Using 'with' with extra brackets for nicer indentation

On Mon, 18 Nov 2019 at 17:55, Random832 wrote: > This particular chain of discussion is regarding a proposal to solve the > problem posed in the original topic by using a parenthesized tuple display, > i.e. code that looks like the following: > > with (open(filename1), open(filename2)) as

[Python-ideas] Re: Fwd: re.findfirst()

On Tue, 3 Dec 2019 at 12:07, Steven D'Aprano wrote: > > I'm sorry Juancarlo, it's not clear to me what *precisely* your proposal > is. Are you asking for "findfirst" to be a builtin? A regex helper > function? A method on regex objects? Something else? > My impression is that he was asking for a

[Python-ideas] Re: Archiving Threads / Closing Threads

On Tue, 3 Dec 2019 at 19:52, Richard Damon wrote: > > Mailman, the manager for the mailing list doesn’t offer any such option. The > closest that could be done is if a topic just goes on too long, a filter > could be added to the list configuration which holds for moderation messages > which

[Python-ideas] Re: Argumenting in favor of first()

On Wed, 11 Dec 2019 at 01:15, Tim Peters wrote: > It's fair enough, although rather than "wrong" I'd say more that it's > inappropriately applying design principles that work well in most of > Python's libraries to an area where they don't. The very fact that > half the itertools docs are

[Python-ideas] Re: PEP 584: Add + and += operators to the built-in dict class.

On Fri, 18 Oct 2019 at 14:33, Richard Musil wrote: > I have no problem with any example you mentioned above, yet I consider > proposed meaning for '+' symbol in this PEP context fundamentally different > from either "arithmetic" or "concatenation" meaning, used in the previous > examples,

[Python-ideas] Re: PEP 584: Add + and += operators to the built-in dict class.

On Mon, 21 Oct 2019 at 14:55, David Mertz wrote: > What is proposed in this PEP is to add a meaning for dct1+dct2 that would be > well defined, but that would be DIFFERENT from the "one obvious meaning." For me, what's coming out is that there *is* no "obvious meaning". People expect different

[Python-ideas] Re: Python 4000: Have stringlike objects provide sequence views rather than being sequences

On Thu, 24 Oct 2019 at 23:47, Andrew Barnert via Python-ideas wrote: > But again, I don’t think either of these is the reason Python strings being > iterable is a problem; I think it really is primarily about them being > iterables of strings. The *real* problem is that there's a whole load of

[Python-ideas] Re: add a .with_stem() method to pathlib objects

On Tue, 29 Oct 2019 at 17:38, Ethan Furman wrote: > > On 10/29/2019 10:17 AM, Brian Skinn wrote: > > > I feel like the semantics of PurePath.suffix > > (https://docs.python.org/3/library/pathlib.html#pathlib.PurePath.suffix) > > and PurePath.stem define this pretty unambiguously. > > It does

[Python-ideas] Re: add a .with_stem() method to pathlib objects

On Tue, 29 Oct 2019 at 17:08, Andrew Barnert wrote: > > If you wanted my safe_create function to do Mac-like “copy 3 of > spam.eggs.txt” instead of Windows-style “spam.eggs (3).txt”, then you would > end up calling path.with_stem("copy 3 of spam.eggs"), and you would > definitely want the

[Python-ideas] Re: add a .with_stem() method to pathlib objects

On Tue, 29 Oct 2019 at 15:29, Ricky Teachey wrote: > > There are already .with_suffix() and with_name() methods. Including > with_stem() seems obvious, no? As you say, it's a minor thing (either way) but I've never had the need for a `with_stem` method. Do you have a real-life use case (as

[Python-ideas] Re: PEP 584: Add + and += operators to the built-in dict class.

On Fri, 18 Oct 2019 at 14:57, Brandt Bucher wrote: > > Paul Moore wrote: > > All of the above is just my subjective opinion. Objective information is > > likely to only be available by someone looking at a body of real world code > > and demonstrating what difference the

[Python-ideas] Re: Using 'with' with extra brackets for nicer indentation

On Mon, 18 Nov 2019 at 23:42, Oscar Benjamin wrote: > > The definition is clearly and precisely implied by the PEP and the > > semantics of the with statement. A CM is anything that has __enter__ > > and __exit__. See > > https://www.python.org/dev/peps/pep-0343/#standard-terminology. > > That

[Python-ideas] Re: Using 'with' with extra brackets for nicer indentation

On Tue, 19 Nov 2019 at 11:34, Oscar Benjamin wrote: > If I was to propose anything here it would not be to disallow anything > that you can currently do with context managers. Rather the suggestion > would be to: > 1. Clearly define what a well-behaved context manager is. > 2. Add convenient

[Python-ideas] Re: Using 'with' with extra brackets for nicer indentation

On Tue, 19 Nov 2019 at 16:05, Random832 wrote: > > On Tue, Nov 19, 2019, at 07:03, Paul Moore wrote: > > That sounds reasonable, with one proviso. I would *strongly* object to > > calling context managers that conform to the new expectations "well > > behaved", a

[Python-ideas] Re: Using 'with' with extra brackets for nicer indentation

On Tue, 19 Nov 2019 at 19:03, Random832 wrote: > > On Tue, Nov 19, 2019, at 11:26, Paul Moore wrote: > > Because you don't have to create the context manager directly in the > > with statement > > ...what? that's *my* argument. that's *precisely* why I consider op

[Python-ideas] Re: Using 'with' with extra brackets for nicer indentation

On Thu, 14 Nov 2019 at 06:45, Greg Ewing wrote: > > > On Nov 13, 2019, at 10:26, gabriel.ka...@mail.de wrote: > >> with ( > >> open(fname1) as f1, > >> open(fname2) as f2, > >> open(fname3) as f3, > >> open(fname4) as f4 > >> ): > > Maybe you should be able to do something like >

[Python-ideas] Re: Incremental step on road to improving situation around iterable strings

On Mon, 24 Feb 2020 at 16:23, Alex Hall wrote: > Roughly, though I think you might be hearing me wrong. There is lots of > existing code that correctly and intentionally iterates over strings. And > code that unintentionally does it probably doesn't live for long. But if you > took a random

[Python-ideas] Re: Incremental step on road to improving situation around iterable strings

On Mon, 24 Feb 2020 at 20:13, Alex Hall wrote: > > > Conversely, I can't remember a case where I've ever accidentally > > iterated over a string when I meant not to. > > Do you ever return a string from a function where you should have returned a > list containing one string? Or similarly passed

[Python-ideas] Re: IDEA: Allow override of all assignments of a built in type to be a different type

On Thu, 5 Mar 2020 at 09:28, Steve Barnes wrote: > Wouldn’t it be possible to have something along the lines of: > > ``` > from decimal import TreatFloatsAsDecimal > @TreatFloatsAsDecimal > a = 0.1 # These are all now decimals > b = 0.2 > c = 0.3 > > a + b == c # This now works > ``` I'm not at

[Python-ideas] Re: Add a __valid_getitem_requests__ protocol

On Mon, 24 Feb 2020 at 02:44, MRAB wrote: > > On 2020-02-24 02:22, Chris Angelico wrote: > > On Mon, Feb 24, 2020 at 1:00 PM C. Titus Brown wrote: > >> > >> WHATS WRONG WITH TOP POSTING IN ALL CAPS AND NO PUNCTUATION!?!?!?! > >> > >> :) > > > > Oh, it's alright, you just put all the punctuation

[Python-ideas] Re: Incremental step on road to improving situation around iterable strings

On Sun, 23 Feb 2020 at 02:52, Chris Angelico wrote: > > On Sun, Feb 23, 2020 at 1:15 PM Ethan Furman wrote: > > > > On 02/22/2020 04:37 PM, Chris Angelico wrote: > > > > > Do any of the core devs agree with those two assertions? > > > > If posts to -Ideas required core dev agreement this would

[Python-ideas] Re: Communication on mailing lists [was: Add a __valid_getitem_requests__ protocol]

On Mon, 24 Feb 2020 at 08:52, Ethan Furman wrote: > In fact, when I first read Rhodri's post I thought it meant something along > the lines of: programming language -> pie in the sky perfection. Hence, it > is possible to be too terse. I feel that this discussion has got out of hand, and it

[Python-ideas] Re: Really long ints

on the proposed syntax. Paul On Tue, 4 Feb 2020 at 19:12, Tim Peters wrote: > > [Paul Moore ] > > ... > > Can you share a bit more about why you need to do this? In the > > abstract, having the ability to split numbers over lines seems > > harmless and occasionally useful,

[Python-ideas] Re: Really long ints

On Tue, 4 Feb 2020 at 10:39, Steven D'Aprano wrote: > > I've been doing some work with large ints, of well over 100 digits. For > example, this number has 131 digits: > > P = >

[Python-ideas] Re: `raise as` to raise with current exception as cause

On Fri, 7 Feb 2020 at 23:14, Steven D'Aprano wrote: > YMMV and this is just my opinion, but personally I think that exception > chaining is rarely useful even at the best of times. For me, the only > time I care about "raise from" is to suppress exception chaining by > setting the cause to None.

[Python-ideas] Re: Add a __valid_getitem_requests__ protocol

On Tue, 18 Feb 2020 at 20:47, Rhodri James wrote: > > On 18/02/2020 20:33, Soni L. wrote: > > > > > > On 2020-02-18 5:08 p.m., Rhodri James wrote: > >> On 18/02/2020 19:43, Soni L. wrote: > >>> It'd be nice to have a __valid_getitem_requests__ protocol that, if > >>> present, yields pairs such

[Python-ideas] Re: Add a __valid_getitem_requests__ protocol

On Tue, 18 Feb 2020 at 23:40, Steven D'Aprano wrote: > > On Tue, Feb 18, 2020 at 09:04:21PM +, Paul Moore wrote: > > > This looks to me like Lua's `items()` function. > > I can't find that function listed anywhere. > > https://www.lua.org/manual/5.3/ > >

[Python-ideas] Re: PyPI should include PEP 440-compliant version strings for including in install_requires

On Sun, 9 Feb 2020 at 14:39, Soni L. wrote: > > Figuring out versioning is hard. PyPI should encourage semver by > including PEP 440 version strings that you can copy and paste into > install_requires. I don't understand what you mean by **PyPI** including version strings. PyPI just publishes

[Python-ideas] Re: Add Binary module.

On Sun, 16 Feb 2020 at 16:07, wrote: > > what about > >>binary.ones_complement(0b110011) > > or should we use something like "bitstring". https://pypi.org/project/bitstring/ Paul ___ Python-ideas mailing list -- python-ideas@python.org To

[Python-ideas] Re: Add Binary module.

On Sun, 16 Feb 2020 at 15:34, wrote: > > I'll show the example using one's and two's complement. > >>binary.ones_complement(110011) > 001100 But these aren't standard Python types - well, technically, 110011 is 1,100,111,111 - 1 billion, 100 million 111 thousand one hundred and

[Python-ideas] Re: Traits

On Sat, 15 Feb 2020 at 12:17, Alex Walters wrote: > > Telling someone you are trying to convince to do something to go learn > something else to "get on your level" as the youth would put it... is not how > you get people to agree with you. > > To summarize this thread, as I see it so far > > *

[Python-ideas] Re: Enhancing Zipapp

On Thu, 9 Jan 2020 at 11:00, Abdur-Rahmaan Janhangeer wrote: > This proposal is not solving any problem at all > -- > This proposal aims at enhancing zipapp. Zipapp solved the problem. Zipapp > had an aim. This proposal aims at helping

[Python-ideas] Re: Enhancing Zipapp

On Thu, 9 Jan 2020 at 18:15, Abdur-Rahmaan Janhangeer wrote: > > I have taken Java as an example (you can refer to the draft here > ) > as Python > shares some similarities in having a VM, having bytecodes and being >

[Python-ideas] Re: Enhancing Zipapp

> Not negative at all, i'm going to do it. Further up in the thread Mr. Barry > Scott proposed the reviewing > of available solutions and further up i put it in the todo list. I'm doing > it, just that there's no way of putting > a Python thread to "stop mode - author addressing issues". lol,

[Python-ideas] Re: Change List Metadata

On Wed, 15 Jan 2020 at 13:37, Hunter Jones wrote: > > Hey everyone, > > I recently used list.count() in a coding interview and the question arose > about how scale-able this solution was for sufficiently large input. > Currently, list.count iterates through the list, incrementing the count as

[Python-ideas] Re: Compound statement colon (Re: Re: Improve SyntaxError for obvious issue:)

On Sat, 18 Jan 2020 at 02:32, Josh Rosenberg wrote: > > The colon remains syntactically necessary in some cases, particularly to > disambiguate cases involving one-lining (no block involved). Stupid example: > If the colon is optional, what does: > > if d +d > > mean? Is it a test of the value

[Python-ideas] Re: Make `del x` an expression evaluating to `x`

On Thu, 12 Mar 2020 at 16:42, Eric Wieser wrote: > > Do you have an example of an application where this sort of > > micro-optimisation is significant enough to justify a fairly major language > > change? > > As an example of these optimizations being valuable, see >

[Python-ideas] Re: Make `del x` an expression evaluating to `x`

On Thu, 12 Mar 2020 at 16:57, Eric Wieser wrote: > > It looks like actually this can be be built as a function today: > > def move(name): > return inspect.currentframe().f_back.f_locals.pop(name) > > Which works as follows, but it feels awkward to pass variable names by > strings

[Python-ideas] Re: Make `del x` an expression evaluating to `x`

On Thu, 12 Mar 2020 at 15:06, Eric Wieser wrote: > will print the same id three times. However, when used as a list > comprehension, the optimization can't step in, and I have no way of using the > `del` keyword > > >>> [id(v) for v in itertools.combinations([1, 2, 3], 1)] >

[Python-ideas] Re: Possible Addition to Python Language: Marked Sub-condition

On Sun, 8 Mar 2020 at 15:02, Shrinivas Kulkarni wrote: > > Hello Everyone > > While writing python code, I frequently come across the need to do > certain tasks based on combined conditions. > > Much of the task for all the sub-conditions are common but some are > specific to one or more of these

[Python-ideas] Re: Make `del x` an expression evaluating to `x`

On Thu, 12 Mar 2020 at 17:20, Chris Angelico wrote: > > What is to stop a Python implementation (not CPython, maybe, but some > > other one) from discarding the object in x as soon as it's > > unreferenced by the (del x) expression? Then y wouldn't be able to > > hold that value. After all, in

[Python-ideas] Re: zip should return partial results in StopIteration

On Tue, 21 Apr 2020 at 15:25, Eric V. Smith wrote: > > In your proposal, what would next(zip([0], [], [0])) result in? > > > This point still stands. ... and for an even more non-obvious case, next(zip(itertools.cycle([0]), [], [0])) (do we just return *one* element that's not been consumed, or

[Python-ideas] Re: zip(x, y, z, strict=True)

On Tue, 21 Apr 2020 at 15:49, Brandt Bucher wrote: > > Of course, the fact that zip() is the shorter form that everyone is used to > > means that, even if a strict argument is added, few people will bother > > adding it. > > I know that I, and everyone on my team, would use it frequently! To

[Python-ideas] Re: zip(x, y, z, strict=True)

On Tue, 21 Apr 2020 at 17:53, Serhiy Storchaka wrote: > > 21.04.20 19:35, Paul Moore пише: > > Hence my suggestion that maybe it's not so much an > > (actionable) exception that people want as an assertion. > > What do you mean by assertion? Raising an AssertionError? Cras

[Python-ideas] Re: zip(x, y, z, strict=True)

On Tue, 21 Apr 2020 at 16:28, Dan Sommers <2qdxy4rzwzuui...@potatochowder.com> wrote: > > On Tue, 21 Apr 2020 16:05:54 +0100 > Paul Moore wrote: > > > To be clear - would you catch the error in your code? What would you > > do when it was raised? Or are you simply

[Python-ideas] Re: Explicitly defining a string buffer object (aka StringIO += operator)

On Wed, 1 Apr 2020 at 02:07, Steven D'Aprano wrote: > Paul has not suggested making StringIO look and feel like a string. > Nobody is going to add 45+ string methods to StringIO. This is a minimal > extension to the StringIO class which will allow people to improve their > string building code

[Python-ideas] Re: macaddress or networkaddress module

On Mon, 6 Apr 2020 at 04:14, Stephen J. Turnbull wrote: > That's OK for developers on their "own" machines, but I think there > are still a lot of folks who need approval from corporate (though I > haven't heard from Paul Moore on that theme in quite a while, maybe > it's

[Python-ideas] Re: Aside RE: Re: macaddress or networkaddress module

n the current situation. > > Obviously, since the script is intended to work out how to get to PyPi, I > needed to stick 100% to the standard libraries. > > -Original Message- > From: Paul Moore > Sent: 06 April 2020 09:11 > To: Stephen J. Turnbull >

[Python-ideas] Re: About python3 on windows

red installation > in this case, which is at the very least problematic when using > "#!/usr/bin/env python3" in an active virtual environment. Paul Moore > will probably suggest that the script should use "#!/usr/bin/env > python" instead, Nope, I agree with you

[Python-ideas] Re: About python3 on windows

On Thu, 26 Mar 2020 at 15:52, Barry Scott wrote: > > > On 25 Mar 2020, at 16:53, Paul Moore wrote: > > > > On Wed, 25 Mar 2020 at 16:10, Eryk Sun wrote: > > > >> The py launcher's "env" command searches PATH for anything from > >> "py

[Python-ideas] Re: About python3 on windows

On Thu, 26 Mar 2020 at 22:11, Cameron Simpson wrote: > > It seems to me that there is a deliberate choice to _not_ install the > "python3" executable name when installing Python 3 on Windows, and to my > eye that is/was a _bad_ choice. I would like to see a good explaination > as to why that

[Python-ideas] Re: Explicitly defining a string buffer object (aka StringIO += operator)

On Thu, 2 Apr 2020 at 04:59, Steven D'Aprano wrote: > > On Wed, Apr 01, 2020 at 09:25:46PM -0400, Kyle Stanley wrote: > > > While I agree that it's sometimes okay to go outside the strict bounds of > > "only one way to do it" > > The Zen of Python was invented as a joke, not holy writ, and as a

[Python-ideas] Re: About python3 on windows

On Wed, 25 Mar 2020 at 11:43, Barry Scott wrote: > I think the reasoning is that the whole point of the py.exe is to avoid having > users edit their PATH on Windows. And further the thinking goes that > you do not need the alternatively named python programs. The alternatively named programs

[Python-ideas] Re: zip(x, y, z, strict=True)

On Thu, 7 May 2020 at 01:07, Christopher Barker wrote: > 3) Add a ternary mode flag to zip > zip(*iters, mode = ('shortest' | 'equal' | 'longest'), fillvalue=None) You missed itertools.zip_longest(*iters, fillvalue=None) from this one. Unless you're proposing to drop itertools.zip_longest, the

[Python-ideas] Re: dunder methods for encoding & prettiness aware formal & informal representations

On Sat, 21 Mar 2020 at 06:42, Steven D'Aprano wrote: > > On Sat, Mar 21, 2020 at 12:16:29PM +0900, Stephen J. Turnbull wrote: > > > The way I think of pprint (FWIW, YMMV) is as a debug utility. > > Oh, that's interesting. I mostly think of pretty-printing as a display > utility aimed at end

[Python-ideas] Re: New explicit methods to trim strings

On Sun, 22 Mar 2020 at 17:58, Guido van Rossum wrote: > > On Sun, Mar 22, 2020 at 9:54 AM Christopher Barker > wrote: >> >> On Sun, Mar 22, 2020 at 2:08 AM Barry Scott wrote: >>> >>> >>> Should `-+-+-+Spam'.stripprefix('-+') remove just the first occurence? >>> >>> All of them? Does it

[Python-ideas] Re: Instance method to test equivalence between set and iterable

On Sun, 22 Mar 2020 at 20:01, Steve Jorgensen wrote: > > Currently, the `issubset` and `issuperset` methods of set objects accept > arbitrary iterables as arguments. An iterable that is both a subset and > superset is, in a sense, "equal" to the set. It would be inappropriate for > `==` to

<    1   2   3   4   5   6   7   8   >