Re: [Python-ideas] A decorator to call super()

BTW, if one can come up with a pure-Python implementation for these, I'd like to take a peek at the code, please. On 31 January 2017 at 13:57, Joao S. O. Bueno <jsbu...@python.org.br> wrote: > On 31 January 2017 at 13:05, Thomas Kluyver <tho...@kluyver.me.uk> wrote: >>

Re: [Python-ideas] A decorator to call super()

On 31 January 2017 at 13:05, Thomas Kluyver wrote: > On Tue, Jan 31, 2017, at 02:32 PM, Stephen J. Turnbull wrote: >> Personally, I don't think the explicit invocation is such a big deal >> to need a standardized decorator in the stdlib. > > +1. It's one line either way, and

Re: [Python-ideas] A decorator to call super()

Sure - thanks - I did not even consider the descriptor mechanism, as I got focused in getting the equivalent from the __class__ cell inside the decorator code. And of course, now there is the "__init_subclass__" mechanism - a mixin version using that was as straight forward as it can be as

Re: [Python-ideas] "Immutable Builder" Pattern and Operator

This is easy to do in Python, and we already have NamedTuples and other things. If you need such a builder anyway, this snippet can work - no need for special syntax: https://gist.github.com/jsbueno/b2b5f5c06caa915c451253bb4f171ee9 On 22 January 2017 at 20:54, Serhiy Storchaka

Re: [Python-ideas] Fwd: Define a method or function attributeoutsideof a class with the dot operator

On 13 February 2017 at 00:55, Steven D'Aprano <st...@pearwood.info> wrote: > On Sun, Feb 12, 2017 at 05:01:58PM -0200, Joao S. O. Bueno wrote: > >> You realize now that if we accept this change, and given your example, >> any "well behaved" Python code wi

Re: [Python-ideas] Fwd: Define a method or function attribute outside of a class with the dot operator

I am definetelly -1 to this idea. But since you are discussing this seriously, one nice thing is to recall how Javascript does that: `function () ` is an expression that returns the created function, and thus can be assigned to anything on the left side. Of course, that would throw us back to a

Re: [Python-ideas] Ideas for improving the struct module

I am for upgrading struct to these, if possible. But besides my +1, I am writting in to remember folks thatthere is another "struct" model in the stdlib: ctypes.Structure - For reading a lot of records with the same structure it is much more handy than struct, since it gives one a suitable

Re: [Python-ideas] Ideas for improving the struct module

On 20 January 2017 at 15:13, Nathaniel Smith wrote: > On Jan 20, 2017 09:00, "Paul Moore" wrote: > > On 20 January 2017 at 16:51, Elizabeth Myers > wrote: >> Should I write up a PEP about this? I am not sure if it's justified or >>

Re: [Python-ideas] SI scale factors in Python

On 25 August 2016 at 06:06, Paul Moore wrote: > On 25 August 2016 at 09:54, Ken Kundert wrote: >> 1G -> 1e+09 >> 1M -> 1e+06 >> 1k -> 1e+03 > > While these suffixes are suitable for a scientific context, in a > computing context,

Re: [Python-ideas] Add optional defaults to namedtuple

On 30 November 2016 at 13:09, Ethan Furman wrote: > But even more readable than that is using the NamedTuple class from my aenum > [3] library (and on SO as [3]): > > --> from aenum import NamedTuple > --> class Node(NamedTuple): > --> val = 0 > --> left = 1, 'previous

Re: [Python-ideas] Way to repeat other than "for _ in range(x)"

On 30 March 2017 at 13:10, Markus Meskanen <markusmeska...@gmail.com> wrote: > > > On Mar 30, 2017 19:04, "Joao S. O. Bueno" <jsbu...@python.org.br> wrote: > > On 30 March 2017 at 10:51, Mark E. Haase <meha...@gmail.com> wrote: >> Your examp

Re: [Python-ideas] Way to repeat other than "for _ in range(x)"

On 30 March 2017 at 10:51, Mark E. Haase wrote: > Your example is really repeating two things: > > d = [ [0 for _ in range(5)] for _ in range(10) ] > > But since list() uses * for repetition, you could write it more concisely > as: > > d = [[0] * 5] * 10] > > I'm not picking on

Re: [Python-ideas] Smoothing transition: 'unicode' and 'basestring' as aliases for 'str'?

I see no reason to introduce clutter like this at this point in time - code needing to run in both Py 2 nd 3, if not using something like "six" could do: compat.py try: unicode except NameError: unicode = basestring = str elsewhere: from compat import unicode, basestring Or rather:

Re: [Python-ideas] Optional parameters without default value

Is it just me that find that having the un-assigned parameter raise NameError (or other exception) much more cumbersome than havign a sentinel-value? I definitely don't find it clever - for one, a common default parameter - sentinel or not, can be replaced in a single line of code by an

Re: [Python-ideas] for/except/else

On 1 March 2017 at 06:37, Wolfgang Maier wrote: > Now here's the proposal: allow an except (or except break) clause to follow > for/while loops that will be executed if the loop was terminated by a break > statement. After rethinking over some code I've

Re: [Python-ideas] Towards harmony with JavaScript?

On 11 August 2017 at 16:19, Chris Angelico wrote: > On Sat, Aug 12, 2017 at 5:13 AM, Alberto Berti > wrote: > > Chris> What do you do about all the places where the languages have > > Chris> significantly different semantics? For instance, a

Re: [Python-ideas] a new namedtuple

In the other thread, I had mentioned my "extradict" implementation - it does have quite a few differences as it did not try to match namedtuple API, but it works nicely for all common use cases - these are the timeit timings: (env) [gwidion@caylus ]$ python3 -m timeit --setup "from collections

Re: [Python-ideas] Augmented assignment syntax for objects.

On 25 April 2017 at 19:30, Erik wrote: > And as I also said above, decorators don't cut it anyway (at least not those > proposed) because they blindly assign ALL of the arguments. I'm more than > happy to hear of something that solves both of those problems without >

Re: [Python-ideas] Pseudo methods

Had not this been discussed here earlier this year? (And despite there being perceived dangers to readability in the long term, was accepted?) Here it is on an archive: https://mail.python.org/pipermail/python-ideas/2017-February/044551.html And anyway - along that discussion, despite dislikng

Re: [Python-ideas] Pseudo methods

On 4 August 2017 at 10:31, Paul Moore <p.f.mo...@gmail.com> wrote: > On 4 August 2017 at 14:20, Joao S. O. Bueno <jsbu...@python.org.br> wrote: > > Had not this been discussed here earlier this year? > > > > (And despite there being perceived dangers

Re: [Python-ideas] Dictionary destructing and unpacking.

I ha d not read all the e-mails in the thread - but just to announce to people eager for a similar feature - I have a package on pypi that enables one to do: In [74]: with extradict.MapGetter({'a': 1}) as d: ...: from d import a ...: In [75]: a Out[75]: 1 (just pip install extradict )

Re: [Python-ideas] Language proposal: variable assignment in functional context

I could emulate the "where" semantics as described by Steven using the class statement and eval : I guess it is useful if someone want to try refactoring a piece of "real world" code, and see if it really feels better - then we could try to push for the "where" syntax, which I kinda like: (This

Re: [Python-ideas] A suggestion for a do...while loop

and "while not except" :-/ maybe we just stick with "while True' and put forward a documenting PEP advising linter packages to look for ways of getting out of the loop. On 26 June 2017 at 08:08, Terry Reedy wrote: > On 6/26/2017 12:41 AM, Nick Coghlan wrote: > >> On 26 June

Re: [Python-ideas] + operator on generators

On 25 June 2017 at 20:55, Danilo J. S. Bellini wrote: > On Sun, Jun 25, 2017 at 3:06 PM, lucas via Python-ideas < > python-ideas@python.org> wrote: > >> I often use generators, and itertools.chain on them. >> What about providing something like the following: >> >>

Re: [Python-ideas] Add an option for delimiters in bytes.hex()

On 1 May 2017 at 11:04, Juancarlo Añez wrote: > > On Mon, May 1, 2017 at 9:38 AM, Nick Coghlan wrote: >> >> just support two >> keyword arguments to hex(): "delimiter" (as you suggest) and >> "chunk_size" (defaulting to 1, so you get per-byte chunking by >>

Re: [Python-ideas] Add single() to itertools

On 31 October 2017 at 10:52, Steven D'Aprano <st...@pearwood.info> wrote: > On Tue, Oct 31, 2017 at 10:42:23AM -0200, Joao S. O. Bueno wrote: >> When I need something like this, I usually rop a line on the module >> namespace that goes like: >> >> first = lambda

Re: [Python-ideas] Add single() to itertools

When I need something like this, I usually rop a line on the module namespace that goes like: first = lambda x: next(iter(x)) On 30 October 2017 at 23:09, Steven D'Aprano wrote: > On Tue, Oct 31, 2017 at 07:51:02AM +1100, Cameron Simpson wrote: > >> return the(nodes) >>

Re: [Python-ideas] Have a "j" format option for lists

On 9 May 2018 at 09:39, Facundo Batista wrote: > This way, I could do: > authors = ["John", "Mary", "Estela"] "Authors: {:, j}".format(authors) > 'Authors: John, Mary, Estela' +1. I bit concerned about the relevant whitespace in there, but just a little bit -

Re: [Python-ideas] Alternative spelling for list.append()

Yes - maybe a proposal to have the MutableSequence protocol to define "<<" as "append" would be something with more traction than the original proposal here. No chanegs needed to to the language core, and a = [1,2, 3] a <<= 4 resulting in a == [1, 2, 3, 4] is quite readable, syntactically valid,

Re: [Python-ideas] Pattern Matching Syntax

What about instead of number = match x: 1 => "one" 2 => "two" 3 => "three" 10 => "ten" _ => "anything" number = { 1 => "one" 2 => "two" 3 => "three" 10 => "ten" }.get(x, "anything") No magic syntax with blocks starting inside an assignment, just to start

Re: [Python-ideas] Pattern Matching Syntax

(sorry - my aboe message is about using a dictionary - the "=>" weird tokens should j=be just plain ":" - the point is that Python açready has syntax to do what is asked) On 3 May 2018 at 10:15, Joao S. O. Bueno <jsbu...@python.org.br> wrote: > What about instead

[Python-ideas] Deprecate "slice" on built-ins, move it to "types"?

This is probably too little to justify the compatibility breakage, but is there a motive for the "slice" type to be on built-ins ? (besides people forgot it there at PEP-3000 time?) It is normally used in super-specialized cases, mostly when one is implementing a Sequence type, and even there

Re: [Python-ideas] Asynchronous friendly iterables

On Mon, 20 Aug 2018 at 04:49, Chris Angelico wrote: > > On Mon, Aug 20, 2018 at 5:34 PM, Simon De Greve wrote: > > Do you mean that for loops inside an "async def" statements are always > > executed as 'async for' loops? That's what I wanted to acheive by writing > > the AsyncDict class (c.f.

Re: [Python-ideas] Descouraging the implicit string concatenation

While I personally dislike implicit string concatenation, I've worked in projects that use it, and I, more often than I'd like, use them myself. The problem is that there is no "less typing" way of entering a correct multi-line string - due to multiline string literals preserving the indentation

Re: [Python-ideas] Is there any idea about dictionary destructing?

On 9 April 2018 at 22:10, Brett Cannon <br...@python.org> wrote: > > > On Mon, 9 Apr 2018 at 05:18 Joao S. O. Bueno <jsbu...@python.org.br> wrote: >> >> we could even call this approach a name such as "function call". > > > The harsh sarcasm

Re: [Python-ideas] Is there any idea about dictionary destructing?

I have an idea for an inovative, unanbiguous, straightforward and backwards compatible syntax for that, that evena llows one to pass metadata along the operation so that the results can be tweaked acording to each case's needs. What about: new_data = dict_feed({ "direct": "some data",

Re: [Python-ideas] Fixing class scope brainstorm

On 27 March 2018 at 10:56, Nick Coghlan wrote: > ... Making it so that lambdas > can close over class attributes breaks that equivalence, and if we > were to use the cell based approach I suggest above, the seams would > be visible in the case where a lambda expression

Re: [Python-ideas] Fixing class scope brainstorm

Paul Moore <p.f.mo...@gmail.com> wrote: > On 27 March 2018 at 15:32, Joao S. O. Bueno <jsbu...@python.org.br> wrote: >> Yes - but that would be the intention of the code beign written as in >> your example - >> >> class C: >> x = 1 >>

Re: [Python-ideas] Python octal escape character encoding "wats"

s was no motive for breaking stuff up. Thank your for the lengthy reply!! > > On Sat, Nov 10, 2018 at 12:42 PM Joao S. O. Bueno > wrote: > > > > I just saw some document which reminded me that strings with a > > backslash followed by 3 octal digits. When a backslash is

[Python-ideas] Python octal escape character encoding "wats"

I just saw some document which reminded me that strings with a backslash followed by 3 octal digits. When a backslash is followed by 3 octal digits, that means a character with the corresponding codepoint and all is well. The "valid scenaario": In [42]: "\777" Out[42]: 'ǿ' The problem is when

Re: [Python-ideas] Add regex pattern literal p""

I am a full -1 on this idea - > Two shortcomings: > > 1, Elevating a class in a module (re.Pattern) to language level, this > sounds not very natural. > This makes Python looks like Perl. > > 2, We can't use regex module as a drop-in replacement: import regex as re > IMHO, I would like to see

Re: [Python-ideas] Multi-line string indentation

/me also would be strongly in favor of this. "+1 " . Even taking in consideration the added complexity . On Fri, 8 Feb 2019 at 13:26, Paul Ferrell wrote: > I particularly like the str.dedent() idea. Adding yet another string > prefix adds more complexity to the language, which I'm generally

Re: [Python-ideas] Making code objects filename an absolute path.

On Fri, 24 May 2019 at 16:49, Batuhan Taskaya wrote: > > changing this will probably break code > It is why i'm suggesting making the real transition at 4.0 and adding a > future flag for now. > It is also not reasonable to suppose that "since python 4 is looming in the horizon we can schedule

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

ync tasks. > Why do we need another API? > > On Fri, Jun 14, 2019 at 4:43 PM Joao S. O. Bueno > wrote: > > > > Regardless of a mechanism to counting time, and etc... > > > > Maybe a plain and simple adition to asincio would be a > > context-switching cal

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

Regardless of a mechanism to counting time, and etc... Maybe a plain and simple adition to asincio would be a context-switching call that does what `asyncio.sleep(0)` does today? It would feel better to write something like `await asyncio.switch()` than an arbitrary `sleep`. On Fri, 14 Jun

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

So - Now thinking on the problem as a whole - I think maybe a good way to address this is to put the logic on "counting N interations or X time and allowing switch" - the logic you had to explicitly mingle in your code in the first example, in a function that could wrap the iterator of the `for`

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

suspends the current task, allowing other tasks to run. > Ok, I agree this, or an improved version of this sentence to explicitly illustrate the "sleep(0)" case is enough. > > On Fri, Jun 14, 2019 at 5:06 PM Joao S. O. Bueno > wrote: > > > > > it is very well

[Python-ideas] Re: Comparison operator support (>= and <=) for type

And yet: This is trivial to implement in a custom metaclass - and maybe it would make default type too "noisy". I am -1 on this going into normal classes, and +0 for having a colaborative metaclass with __lt__, __eq__ and such implementing these on the stdlib. Maybe living in "types". On

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

it to the stdlib. On Fri, 14 Jun 2019 at 11:58, Joao S. O. Bueno wrote: > So - > > Now thinking on the problem as a whole - > I think maybe a good way to address this is to put the logic on > "counting N interations or X time and allowing switch" - the logic yo

Re: [Python-ideas] Syntax to conditionally define a field in a dict

Calling upon ol' Guidos Time Machinne: In [31]: def create(val1): ...: data = { ...: **({"val1": "me here"} if val1 else {}) ...: } ...: return data ...: In [32]: create(False) Out[32]: {} In [33]: create(True) Out[33]: {'val1': 'me here'} Now, please, just

[Python-ideas] Re: Make tuple a context manager

Modifying the fundamental tuples for doing that is certainly overkill - but maybe a context-helper function in contextlib that would proper handle all the corner cases of some code as I've pasted now at: https://gist.github.com/jsbueno/53c059380be042e2878c08b5c10f36bf (the link above actually

[Python-ideas] Re: Coding using Unicode

Adrien - please take note that since you already wrote about "everybody could update their environment and editors" to support unicode, things like what you want (emojis in identifiers) can be supported at programming editor (and plug-ins and extensions for those) level - without impairing anyone

[Python-ideas] Re: Conditional dict declarations

Also, if one have in mind that dict addition with the `+` operator had been recelently approved, as of Python 3.9 it will be ok to write: ``` return ({ 'user_id': user_id,} + ({'max_results': max_results} if max_results else {}) + ({'active': active} if active is not None

[Python-ideas] Re: Support for atomic types in Python

May I ask how acquainted you ar with parallel code, including multi-threading, in Python? Because as far as I can perceive none of the types or operations you mention have any race conditions in multi-threaded Python code, and for multi-process or async code that is not a problem by design but

[Python-ideas] Re: Support for atomic types in Python

efore very fast also. So, what I am proposing is a similar > object to value to which operations like add, sub, xor, etc are atomic. > Therefore, I wouldn't have to use lock at all for synchronization. Updates > to these values can be made very easily by using calls such as > __sync

[Python-ideas] Re: Conditional dict declarations

On Sat, 7 Sep 2019 at 01:24, Steven D'Aprano wrote: > On Sat, Sep 07, 2019 at 12:35:09AM -0300, Joao S. O. Bueno wrote: > > > Well - the idea showed up here, and got an immediate "that is nice, let's > > do it" from you, followed by approval from a lot more

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

On Thu, 8 Aug 2019 at 18:53, Chris Angelico wrote: > On Fri, Aug 9, 2019 at 6:31 AM Richard Musil wrote: > > > > Chris Angelico wrote: > > > > > 2) Should there be a protocol obj.__json__() to return a string > > > representation of an object for direct insertion into a JSON file? > > > > >

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

So - I think that is clear by now that in your case you really are not loosing any precision with these numbers. However, as noted, there is no way to customize Python JSON encoder to encode an arbitrary decimal number in JSON, even though the standard does allow it, and Python supports then via

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

On Fri, 9 Aug 2019 at 14:49, Richard Musil wrote: > Joao S. O. Bueno wrote: > > > However, as noted, there is no way to customize Python JSON encoder > > to encode an arbitrary decimal number in JSON, even though the standard > does > > allow it, and Python suppor

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

On Fri, 9 Aug 2019 at 19:53, Richard Musil wrote: > Joao S. O. Bueno wrote: > > yes, just that it should be called dump_as_float and take either a > > class > > or a tuple-of-classes > > I saw kind of symmetry with the `parse_float` which only accepted one > c

[Python-ideas] Re: Skip modules by default in star-import

Just because du to the side tracking it is looking like "it might be a nice idea": IMHO, this is not. and I second Brendan's arguments - This fix too litle, and normally just for beginners who happen to use * imports in code that will selfon be put to critical use. (and even if it does, the extra

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

This has being thought, asked, and even agreed as nice thing before, however, it is blocked due to ambiguity on the syntax for some corner cases - and, I may be wrong n that, it would not be possible to do with the current parser (and Python is not shifting to a more complex parser for this

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

> I think it could also be done by letting the grammar parse it as a tuple and then having an extra (non-declarative) fixup step. But that obviously makes parsing more complicated to think through, and to document, etc. Just throwing this idea in: what about an approach _not touching_ the parser

[Python-ideas] Re: frozen dataclasses attribute initialization

I think the simpler route to go there (allow the use of `self.attr=` until after ___post_init__ is run is simply to add another flag attribute, that tells wether "initialization is over", and respect that flag in the added `__setattr__`. The hook calling `__post_init__` would then set that flag

[Python-ideas] Re: Allow kwargs in __{get|set|del|}item__

So, in short, your idea is to allow "=" signs inside `[]` get notation to be translated to dicts on the call, in the same way comma separated values are translated to tuples? I see no backwards syntax incompatibility in that, and the tuple-translation is indeed quite a helper in many cases. The

[Python-ideas] Re: New syntax for decorators that are compatible with both normal and async functions

The idea on the OP can be fully implemented with ~10 lines of code in a decorator - which could be further factored out into a decorator-for-decorators: ``` import asyncio, inspect def hybrid_decorator(func): coro = inspect.iscoroutinefunction(func) if coro: async def

[Python-ideas] Re: PEP 572: Is it a good ideas that walrus operator can be used in assertions since it causes side effects?

Yes = The Walrus operator, poorly used, can caused the problem in the OP, and many, many others. It does not make a difference - we discussed and got to the conclusion that the benefits of having it surpass whatever bad uses people put it for. It clearly does not make sense to try to modify

[Python-ideas] Re: Proposal: Complex comprehensions containing statements

I am disliking this proposal at all, more from a gut-feel than anything. But then I just did `import this` and pasted bellow the parts I think this violates. While we all have to keep in mind that the "zen of Python" are more guidelines than absolute standards, they still are _good_ guidelines

[Python-ideas] Re: Should dataclass init call super?

There is a way to have dataclasses as they are now behave collaboratively with a further decorator. For Python 3.8 livefcycle such decorator could live in an external package - if its good, it could go into the stdlib, or maybe, another "dataclasses.collaborative_dataclass" would already create

[Python-ideas] Re: Should dataclass init call super?

g to statically guess parameters to a class' __init__ . Anyway, I think it is a way to go if one needs the collaborative dataclasses now. On Wed, 15 Apr 2020 at 17:45, Joao S. O. Bueno wrote: > There is a way to have dataclasses as they are now behave collaboratively > with > a further d

[Python-ideas] Re: Keyword arguments self-assignment

On Fri, 17 Apr 2020 at 17:06, David Mertz wrote: > I'm kinda leaning -0.5 even on the form that I think is least bad (the > mode switch approach). > > If typing the same variable from the caller to use in the parameter is > really too much repetition, you could maybe just do this: > > For what

[Python-ideas] Re: "except BaseException with f as result"

On Tue, 7 Apr 2020 at 23:17, Greg Ewing wrote: > On 8/04/20 1:14 pm, Soni L. wrote: > > > def get_property_values(self, prop): > > try: > > factory = self.get_supported_properties()[prop] > > except KeyError with keyerror_handler; > > iterator =

[Python-ideas] Re: Limit 'import as' syntax

The part of "as X" of either "import foo.bar as X" or "from foo import bar as X" does _one thing_ and is fully self-consistent. The part of "import foo.bar" and "from foo import bar" does different things, that sometimes are interchangeable, and in some cases may have different results -

[Python-ideas] Re: Limit 'import as' syntax

on, 30 Mar 2020 at 12:11, Joao S. O. Bueno wrote: > The part of "as X" of either "import foo.bar as X" or "from foo import bar > as X" does _one thing_ and is fully self-consistent. > > The part of "import foo.bar" and "from foo impor

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

I agree with the arguments the OP brings forward. Maybe, it should be the case of having an `StringIO` and `BytesIO` subclass? Or better yet, just a class that wraps those, and hide away the other file-like methods and behaviors? That would keep the new class semantically as a string, and they

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

Thank you for the lengthy reply anyway. That said, anyone could tell about small, efficient, well maintained "mutable string" classes on Pypi? On Mon, 30 Mar 2020 at 14:07, Andrew Barnert wrote: > On Mar 30, 2020, at 08:29, Joao S. O. Bueno wrote: > > > >  > >

[Python-ideas] Re: Adding a "once" function to functools

I have needed this often enough (and used `lru_cache` ) to say I am full +1 on it. It should not hurt have `functools.once`. On Sun, 26 Apr 2020 at 11:09, Tom Forbes wrote: > Hello, > I would like to suggest adding a simple “once” method to functools. As the > name suggests, this would be a

[Python-ideas] Re: Auto-assign attributes from __init__ arguments

May 2020 at 11:52, Joao S. O. Bueno wrote: > > Here - with the current inspect.Signature, it is straightforward > to get a decorator that can do that covering most, if not all, > corner cases, and even adding some extra functionality: > > https://gist.

[Python-ideas] Re: Improve handling of Unicode quotes and hyphens

Wow - a lot going on this thread - despite what to do seemingly really obvious: of course showing which character triggered the error along with a proper plain English phrase is enough. The Fortran anecdote in the beginning of the thread is a false analogy, since the program _will_ _not_ run

[Python-ideas] Re: Auto-assign attributes from __init__ arguments

On Wed, 6 May 2020 at 15:08, Ricky Teachey wrote: > > On Wed, May 6, 2020 at 1:44 PM Alex Hall wrote: >> >> I think this looks great, I can't think of anything wrong with it. >> >> Could we put this into the standard library, so that IDEs and linters are >> programmed to recognise it? > > > If

[Python-ideas] Re: Support max heaps in heapq module

It is easy to have a wrapper class around the heapq functions so that you can use an arbitrary comparison on the heap. I have an answer with such an snippet, that got some activity today - maybe exactly due to your questioning:

[Python-ideas] Re: Auto-assign attributes from __init__ arguments

On Mon, 4 May 2020 at 19:13, Lewis Ball wrote: > > I had a similar solution with a decorator using inspect.getfullargspec but it > is pretty fiddly and it is pretty easy to miss > some of the edge cases. Having a standard implementation would definitely > take care of this. And I imagine >

[Python-ideas] Re: Auto-assign attributes from __init__ arguments

On Wed, 6 May 2020 at 18:56, Lewis Ball wrote: > > Joao S. O. Bueno wrote: > > Here - with the current inspect.Signature, it is straightforward > > to get a decorator that can do that covering most, if not all, > > corner cases, and even adding some extra

[Python-ideas] Re: Auto-assign attributes from __init__ arguments

f __init__(self, a, b, c=3): pass a = A(1, 2) assert a.a == 1 and a.b == 2 and a.c == 3 """ ``` On Wed, 6 May 2020 at 11:11, Joao S. O. Bueno wrote: > > On Mon, 4 May 2020 at 19:13, Lewis Ball wrote: > > > > I had a similar solution with a decorator us

[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->

On Thu, 21 May 2020 at 18:15, Mike Miller wrote: > > > On 2020-05-21 05:48, Joao S. O. Bueno wrote: > > Input _is_ hard or rare. Deal with it. > > Even the font is not uniformily configured across systems, and a glyph one > > does see here may not show properl

[Python-ideas] Re: A shortcut to load a JSON file into a dict : json.loadf

On Fri, 11 Sep 2020 at 19:50, David Mertz wrote: > I like the idea of having these functions, but I don't like overloading > the argument to a function with "filename or file-like object" as is common > in libraries like Pandas. I think there are a few places the standard > library does it, but

[Python-ideas] Re: 'Infinity' constant in Python

On Fri, 4 Sep 2020 at 19:12, Cade Brown wrote: > I mentioned that in my post; however it doesn't satisfy the problems I > have (mainly being that eval(repr(x))==x) > In [1]: from math import inf In [2]: eval(repr(inf)) == inf Out[2]: True "works for me" > > I still think unifying it as a

[Python-ideas] Re: New feature

On Fri, 16 Oct 2020 at 08:00, Chris Angelico wrote: > On Fri, Oct 16, 2020 at 8:21 PM Rob Cliffe via Python-ideas > wrote: > > > > > > > > On 13/10/2020 23:35, Guido van Rossum wrote: > > > Can one of the educators on the list explain why this is such a > > > commonly required feature? I

[Python-ideas] Re: Function composition

Really, I don't think new syntax is needed for that, as it is trivially resolved by a function call (I would type an example but Ricky's answer covers it) Moreover, such a callable, or other helper-callables can trivially enable ways of connecting the piped values through specific

[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->

On Wed, 20 May 2020 at 17:17, Mike Miller wrote: > > > On 2020-05-20 00:44, Chris Angelico wrote: > > If you think that a keyboard with fancy arrows on it will take off any > > quicker, you're extremely hopeful. > > While I'm not sure how useful this is in the long run, the oft mentioned >

[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->

On Thu, 21 May 2020 at 10:06, Thierry Parmentelat wrote: > > > > > On 21 May 2020, at 14:48, Joao S. O. Bueno wrote: > > > > (I had a coleague once which did > > set a special VIM config to display "!=" as > > "[can't type, math 'differen

[Python-ideas] Re: execute function on iterator items without changing or consuming iterator

this seems nice. It just seems that the obvious way to do it would be: def tap(iter_, func): for item in iter_: func(item) yield item I think it can be nice, but more as cookbook material than an actual itertools function. On Sun, 25 Oct 2020 at 14:38,

[Python-ideas] Re: bpo-41231: wraps default behavior with __annotations__

"3" would "break stuff around". I'd be glad if "2" worked - but that have to be well documented and easy to see. "1" is basically a workaround the current behavior, and people who care for it will have to continue doing that until Python 3.10 is widespread - but ultimately it basically requires

[Python-ideas] Re: Universal set

You could create such a class with a few lines of code by inheriting from collections.abc.MutableSet You as anyone with a pontual problem that would benefit from such a construct - I can't see why/when this would be useful unless in a project already dealing with symbolic/lazy mathematical

[Python-ideas] Re: Decorators for class non function properties

When one needs a custom property, the easy, readable, and that already works way to create then is just to create an instance of the their class and assign the instance to the desired class attribute. All the class have to do is to have the methods that identify it as a descriptor: "__get__" and

[Python-ideas] Re: Decorators for class non function properties

On Thu, 6 Aug 2020 at 00:14, Guido van Rossum wrote: > On Wed, Aug 5, 2020 at 7:06 PM Steven D'Aprano > wrote: > >> *blinks* >> >> When did this happen? >> >> I'm on Python-Ideas, Python-Dev, and I get announcements of new issues >> on the bug tracker, and I don't recall ever seeing this

[Python-ideas] Re: Add __eq__ to colletions.abc.Sequence ?

On Wed, 1 Jul 2020 at 03:37, Random832 wrote: > On Tue, Jun 30, 2020, at 10:57, Guido van Rossum wrote: > > I don't recall why this was done. It seems somewhat odd, since Set and > > Mapping in the same module do have __eq__. I don't care much for the > > default implementation though. > > > > >

[Python-ideas] Re: Access (ordered) dict by index; insert slice

> One way to think about is that adding indexing to the views would NOT make them Sequences, it would simply provide that one feature As you can see in an e-mail from me in another thread yesterday - `__eq__`, oddly enough, is not currently a Sequence method, if we take Sequences to be what is

[Python-ideas] Add __eq__ to colletions.abc.Sequence ?

Is there any reason why collections.abc.[Sequence|MutableSequence] do not have "__eq__" for free? I was writing some tests now and was caught by surprise there. (chcking the docs, if my custom MutbaleSequence also inherits from "collections.abc.Set" I will have working "__eq__" - and "__ne__",

[Python-ideas] Re: Add __eq__ to colletions.abc.Sequence ?

ed in this list. On the other hand I can see no reason why these comparisons are not there, and can't think of many ways code would break if they were introduced (such code would have to be relying on the default "is" operation of the default "object.__eq__") > > On Tue, Jun 30, 20

  1   2   >