[Python-ideas] Re: PEP8 mandatory-is rule
forming code before the change is still conforming. Moving forward, > I would expect that regular code will trend towards using == in such a > case, reserving is for the rare cases where it is needed for > correctness. > > PEP8 was originally just for Python implementations, so why is this > change needed? Because as a practical matter, the vast majority of > code that is using PEP8 is not part of a Python implementation. This > may not have been the original mission of PEP8, but it is how things > have worked out. > > Now we are in a situation where the rules in PEP8 are sent out to this > ocean of Python programmers of many different ability levels writing > regular code that is not a Python implementation. One could imagine a > separate PEP800 style guide for regular code, but we don't need to do > that, because in almost all cases PEP8 works great for regular code. I > have taught thousands of new Python programmers, and the only place > where PEP8 serves them poorly is this mandatory-is rule. Therefore > instead of a separate style guide for regular code, I propose an > exception for this one problem rule. > > Ultimately this comes down to the question - should PEP8 push regular, > not-Python-implementation code to use is for singletons in cases where > == works perfectly? Seeing how effortless it is for programmers to use > == as their first choice, I think PEP8 should allow that practice. > > Best, > > Nick > _______ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/JWLKBT2YYDGFS76Z37FZJNZPEDVXOLCW/ > Code of Conduct: http://python.org/psf/codeofconduct/ > > -- CALVIN SPEALMAN SENIOR QUALITY ENGINEER calvin.speal...@redhat.com M: +1.336.210.5107 [image: https://red.ht/sig] <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted> ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/CE2USF7U2PCQVMLK3SYRCOLH5XA4IILL/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: slices syntactic sugar
An alternative suggestion, which works today (... is a valid object called Ellipsis): Foobar.search( attr1="foo", attr2=[10, ...], attr3=[42, ..., 50] ) On Thu, Aug 12, 2021 at 8:44 AM wrote: > Hi. I am working on a kinda-ORM library, which usage often implies to > request data within specific ranges: > > Foobar.search( > attr1="foo", > attr2=gt(10), > attr3=between(42, 50) > ) > > The use of "gt" or "between" methods to describe those operations feels a > bit cumbersome (as it is long to write, and you need to import those > functions in a lot of files), and I though it could be more pythonic to use > slices instead. > > Foobar.search( > attr1="foo", > attr2=slice(10), > attr3=slice(42, 50) > ) > > I suggest an alternative way to instanciate slices, that would look like > this: > > Foobar.search( > attr1="foo", > attr2=[10:], > attr3=[42:50] > ) > > What do you think? > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/XLURWAH6NURBVQSYUGTMK5TQTRD7LNFI/ > Code of Conduct: http://python.org/psf/codeofconduct/ > > -- CALVIN SPEALMAN SENIOR QUALITY ENGINEER calvin.speal...@redhat.com M: +1.336.210.5107 [image: https://red.ht/sig] <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted> ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/RD2NVBS5XIBB3YCEVGDW5H6RFTQAGLUU/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Namespaces!
OK, tell me what this does. namespace A: namespace B: foo = bar On Sat, May 1, 2021 at 7:55 PM Matt del Valle wrote: > Hi all! > > So this is a proposal for a new soft language keyword: > > namespace > > I started writing this up a few hours ago and then realized as it was > starting to get away from me that there was no way this was going to be > even remotely readable in email format, so I created a repo for it instead > and will just link to it here. The content of the post is the README.md, > which github will render for you at the following link: > > https://github.com/matthewgdv/namespace > > I'll give the TLDR form here, but I would ask that before you reply please > read the full thing first, since I don't think a few bullet-points give the > necessary context. You might end up bringing up points I've already > addressed. It will also be very hard to see the potential benefits without > seeing some actual code examples. > > TLDR: > > - In a single sentence: this proposal aims to add syntactic sugar for > setting and accessing module/class/local attributes with dots in their name > > - the syntax for the namespace keyword is similar to the simplest form of > a class definition statement (one that implicitly inherits from object), so: > > namespace some_name: >... # code goes here > > - any name bound within the namespace block is bound in exactly the same > way it would be bound if the namespace block were not there, except that > the namespace's name and a dot are prepended to the key when being inserted > into the module/class/locals dict. > > - a namespace block leaves behind an object that serves to process > attribute lookups on it by prepending its name plus a dot to the lookup and > then delegating it to whatever object it is in scope of > (module/class/locals) > > - This would allow for small performance wins by replacing the use of > class declarations that is currently common in python for namespacing, as > well as making the writer's intent explicit > > - Crucially, it allows for namespacing the content of classes, by grouping > together related methods. This improves code clarity and is useful for > library authors who design their libraries with IDE autocompletion in mind. > This cannot currently be done by nesting classes. > > I live in the UK so I'm going to bed now (after working on this for like > the last 6 hours). I'll be alive again in maybe 8 hours or so and will be > able to reply to any posts here then. > > Cheers everyone :) > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/7DAX2JTKZKLRT4CKKBRACNBJLHQUCN6E/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- CALVIN SPEALMAN SENIOR QUALITY ENGINEER calvin.speal...@redhat.com M: +1.336.210.5107 [image: https://red.ht/sig] <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted> ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/CZ43UH73AUT6X23JFEU3SWTDSNBSIGND/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Accepting a function argument of a particular type specified by the user
Great, so what does this mean then? def add(int a: float, float b: int): return a + b On Sun, Apr 25, 2021 at 2:19 PM Shreyan Avigyan wrote: > I am aware of all those libraries that allows us to type check. But it > would be nice to have this feature built-in. I'm not talking about > modifying type annotation but introducing a new feature. Like, > > def add(int a, int b): > return a + b > > If type is not provided then take in any parameter types. Like, > > def example(c): > print(c) > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/BSE7RQ5EL2EFLYY6LTZRY5FARKN2XZW4/ > Code of Conduct: http://python.org/psf/codeofconduct/ > > -- CALVIN SPEALMAN SENIOR QUALITY ENGINEER calvin.speal...@redhat.com M: +1.336.210.5107 [image: https://red.ht/sig] <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted> ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/CIS3PB34YTW3Q6EZ4R5XHJPTTL3IFYJV/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add venv activate command to the venv modules
On Mon, Jan 4, 2021 at 9:47 AM Chris Angelico wrote: > On Tue, Jan 5, 2021 at 1:42 AM Abdur-Rahmaan Janhangeer > wrote: > > > > Greetings list, > > > > put simply, > > > > be able to use > > > > $ python -m venv venv_name activate > > > > To activate an env instead of having each platform have a way of > > handling it > > > > Unfortunately, that wouldn't work. Activating a virtual environment > means setting some env vars in the current shell, and Python is > fundamentally unable to do that - it can only be done within the shell > itself (by sourcing a script). > > You can, of course, simply run the Python executable from that venv, > but activation is *by its nature* a shell feature, and will differ by > shell. > This is true, but... it might be possible to include something more like pipenv's "shell" which spawns a new instance of your shell with the right paths. It effectively achieves the same goal, without needing to source, > > ChrisA > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/SRHBSWZEUGLZG55DGRHQZ4X7VOEPY6XC/ > Code of Conduct: http://python.org/psf/codeofconduct/ > > -- CALVIN SPEALMAN SENIOR QUALITY ENGINEER cspea...@redhat.com M: +1.336.210.5107 [image: https://red.ht/sig] <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted> ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/QV6UHJHTWNMRRBG3YEDJ5NKYHDIJFGRR/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Getting rid of FOR loops and simplifying cicular conviolutions with Circular Indexing
days_of_the_week[14 % 7] There ya go! On Wed, Nov 25, 2020 at 12:51 PM Mathew M. Noel via Python-ideas < python-ideas@python.org> wrote: > If circular indexing is used then instead of using a double FOR loop to > go through a list M times we can iterate from 0 to M*N (where N is the > length of the list) !!! > > > Almost all Machine Learning (ML) algorithms iterate for some predefined > epochs over a large data-set. So a double FOR loop is extremely common in > ML. Using circular indexing gets rid of this extra FOR loop. If we have to > iterate 2 times you can iterate using range(-n,n) but in most cases you > need to iterate over 10 or more epochs in ML. > > > Most scientific applications of Python involve an outer FOR loop which > progressively refines an approximation with an inner FOR loop by going > through a list of items. So circular indexing is useful. In the following I > discuss increasingly compelling reasons for adopting a circular indexing > scheme in Python. > > > Python uses an index of -1 to index the last element in a list. Since -1 > occurs before 0 we might think of the elements of the linear list are being > bent into a circle making the last element occur before the 0th element. > Consider a list with n elements: it would be perfectly reasonable to > address the element 0 of the list using an index of n since n occurs after > n-1 (if we assume that the list is bent into a circle). This feature can > prove to be extremely useful. Consider the following example: > > > days_of_the_week = > ["Sunday","Monday","Tuesday","Wednesday","Thursday","Friday","Saturday"] > > It would be nice if > > days_of_the_week[0] > > is the same as > > days_of_the_week[7] > > is the same as > > days_of_the_week[14] etc > > In other words use modular indexing. In other words if the index is outside > the range 0 to n-1, we simply take the remainder when the index is divided by > n as the index. > Because of the close relationship between finite length sequences and > periodic sequences this feature might simplify scientific computing(circular > convolution etc). > > If circular indexing is used then we don't need the arbitrary rule that -1 > is the index of the last element. Since -1 is the same as n-1 automatically > in modular arithmetic. > > > A trivial objection: "why not use list_name[i%n] whenever we need this > feature?" By the same token we could do away with negative indices and use > -1%n for example when we need to index with -1! > > Its unclear why that people have an irrational preference for indices > that lie to the left of 0 while strongly rejecting the idea of indices that > lie to the right of n-1! > > Python does not raise a "index out of bound" exception for negative > indices like other programming languages. If this negative indexing is a > "feature" (although it allows some fatal errors to slip) then indices above > n-1 can also be considered a feature! > > Are there any deep mathematical reasons for adopting circular convention? > Circular convolution is a most important operation in a wide variety of > scientific disciplines since the Discrete Fourier Transform (DFT) of the > circular convolution of two signals is the product of the transforms. > Because of the universal applicability of Fourier ideas in science and the > close mathematical relationship between finite length and periodic > sequences circular indexing is extensively used in signal processing and > mathematics. > > We can extend the idea of circular indexing to multidimensional arrays. A > 2D array can be folded into a cylinder for indexing. Further this cylinder > can be folded into a toroid to reduce a triple FOR loop to a single FOR > loop. A deep mathematical justification for cylindrical indexing of 2D and > in general nD arrays is offered by the fact that n-dimensional DFT reduces > n-dimensional circular convolution to element-wise multiplication. > > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/5TJYKFLBHB26WEFFQXMY6AGWS34XTIUR/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- CALVIN SPEALMAN SENIOR QUALITY ENGINEER cspea...@redhat.com M: +1.336.210.5107 [image: https://red.ht/sig] <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted> ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/JX2MJS5Y5GH4DMKGVE6N2GTFAUPCVTRJ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: f-strings as assignment targets
I really like the symmetry of this approach.
On Thu, Sep 17, 2020 at 8:37 AM Dennis Sweeney
wrote:
> TL;DR: I propose the following behavior:
>
> >>> s = "She turned me into a newt."
> >>> f"She turned me into a {animal}." = s
> >>> animal
> 'newt'
>
> >>> f"A {animal}?" = s
> Traceback (most recent call last):
> File "", line 1, in
> f"A {animal}?" = s
> ValueError: f-string assignment target does not match 'She turned me
> into a newt.'
>
> >>> f"{hh:d}:{mm:d}:{ss:d}" = "11:59:59"
> >>> hh, mm, ss
> (11, 59, 59)
>
> === Rationale ===
>
> Part of the reason I like f-strings so much is that they reduce the
> cognitive overhead of reading code: they allow you to see *what* is
> being inserted into a string in a way that also effortlessly shows
> *where* in the string the value is being inserted. There is no need to
> "paint-by-numbers" and remember which variable is {0} and which is {1}
> in an unnecessary extra layer of indirection. F-strings allow string
> formatting that is not only intelligible, but *locally* intelligible.
>
> What I propose is the inverse feature, where you can assign a string
> to an f-string, and the interpreter will maintain an invariant kept
> in many other cases:
>
> >>> a[n] = 17
> >>> a[n] == 17
> True
>
> >>> obj.x = "foo"
> >>> obj.x == "foo"
> True
>
> # Proposed:
> >>> f"It is {hh}:{mm} {am_or_pm}" = "It is 11:45 PM"
> >>> f"It is {hh}:{mm} {am_or_pm}" == "It is 11:45 PM"
> True
> >>> hh
> '11'
>
> This could be thought of as analogous to the c language's scanf
> function, something I've always felt was just slightly lacking in
> Python. I think such a feature would more clearly allow readers of
> Python code to answer the question "What kinds of strings are allowed
> here?". It would add certainty to programs that accept strings,
> confirming early that the data you have is the data you want.
> The code reads like a specification that beginners can understand in
> a blink.
>
>
> === Existing way of achieving this ===
>
> As of now, you could achieve the behavior with regular expressions:
>
> >>> import re
> >>> pattern = re.compile(r'It is (.+):(.+) (.+)')
> >>> match = pattern.fullmatch("It is 11:45 PM")
> >>> hh, mm, am_or_pm = match.groups()
> >>> hh
> '11'
>
> But this suffers from the same paint-by-numbers, extra-indirection
> issue that old-style string formatting runs into, an issue that
> f-strings improve upon.
>
> You could also do a strange mishmash of built-in str operations, like
>
> >>> s = "It is 11:45 PM"
> >>> empty, rest = s.split("It is ")
> >>> assert empty == ""
> >>> hh, rest = rest.split(":")
> >>> mm, am_or_pm = s.split(" ")
> >>> hh
> '11'
>
> But this is 5 different lines to express one simple idea.
> How many different times have you written a micro-parser like this?
>
>
> === Specification (open to bikeshedding) ===
>
> In general, the goal would be to pursue the assignment-becomes-equal
> invariant above. By default, assignment targets within f-strings would
> be matched as strings. However, adding in a format specifier would
> allow the matches to be evaluated as different data types, e.g.
> f'{foo:d}' = "1" would make foo become the integer 1. If a more complex
> format specifier was added that did not match anything that the
> f-string could produce as an expression, then we'd still raise a
> ValueError:
>
> >>> f"{x:.02f}" = "0.12345"
> Traceback (most recent call last):
> File "", line 1, in
> f"{x:.02f}" = "0.12345"
> ValueError: f-string assignment target does not match '0.12345'
>
> If we're feeling adventurous, one could turn the !r repr flag in a
> match into an eval() of the matched string.
>
> The f-string would match with the same eager semantics as regular
> expressions, backtracking when a match is not made on the first
> attempt.
>
> Let me know what you think!
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@pyth
[Python-ideas] Re: Type Implications in Python 4 (or 3.9)
Do you mean the type annotations that Python has had for about ten years? And the typing library that uses them to specify type hints to compilers and other tooling? https://docs.python.org/3/library/typing.html On Wed, Aug 26, 2020 at 11:07 AM wrote: > One suggestion I had for the next Python release is to add > type-implication support. Many developers have learned Python, but do not > want to use it since it is slow. An awesome way to fix this is to have > optional type-implications. For example, if you know for sure that variable > x is an int, you can make Python just a bit smaller by somehow specifying > to the interpreter that the variable is an integer. Something like 'x::int > = 5'. By having optional type implications, you can still do everything you > do with normal Python, except you can speed it up a little bit by telling > the Interpreter that this variable is starting off with this datatype. > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/ZGTZNKOSTNTEA3NLJWERIGC3IHG7WU5B/ > Code of Conduct: http://python.org/psf/codeofconduct/ > > -- CALVIN SPEALMAN SENIOR QUALITY ENGINEER cspea...@redhat.com M: +1.336.210.5107 [image: https://red.ht/sig] <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted> ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/V63JTFW5RLUDJ7DAAD5B7R7MV7KECIQO/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Bringing the print statement back
kind of implied call syntax is absolutely the kind of ambiguity that makes a language hard to debug, hard to read, and hard to learn. Second, I don't think we should discount a certain marketing aspect to a change like this. Like it or not, Python 3's changes were contentious for a lot of users. It took way longer than some of us thought to drag the community into the modern incarnation of the language, and there isn't only a small portion of the community that might still be a little bitter about it. Or, who still have to deal with the split between 2 and 3 even today, EOL be damned. What message do we send if we undo one of the most visible changes *now*? We'd send a message that it was all a mistake, and because of the visibility of such a quintessential line of Python print "Hello, World!" It wouldn't just send a message that this one change was a mistake, but that the whole ordeal had always been a mistake. That isn't a can of worms I want to open or ammunition I want to give to naysayers. -- > --Guido van Rossum (python.org/~guido) > *Pronouns: he/him **(why is my pronoun here?)* > <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/NCQX6ZIBREUTLS52VVG3DSZ43OEXJFTT/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- CALVIN SPEALMAN SENIOR QUALITY ENGINEER cspea...@redhat.com M: +1.336.210.5107 [image: https://red.ht/sig] <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted> ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/2MC2TM6QTK6BP6SCQSF6WJG5KHODOAVL/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: zip should return partial results in StopIteration
Which of these would you consider correct? try: next(zip([0], [])) except StopIteration as exc: assert StopIteration.args == (0,) vs try: next(zip([], [0])) except StopIteration as exc: assert StopIteration.args == (0,) On Tue, Apr 21, 2020 at 10:14 AM Soni L. wrote: > I feel like zip could return partial results: > > try: >next(zip([0], [])) > except StopIteration as exc: >assert StopIteration.args == (0,) > > how much would this break? > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/RSSOCK2CWM2MBC6E3SYHP3BDP457OKFX/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- CALVIN SPEALMAN SENIOR QUALITY ENGINEER cspea...@redhat.com M: +1.336.210.5107 [image: https://red.ht/sig] <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted> ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/PSKR4BZKUD3ZEQQIFQTAAHCBGIRE352V/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Keyword arguments self-assignment
I could absolutely see a lot of use for this when it comes to rebinding names in callbacks and the like. for i in range(10): callLater(delay, lambda i=: print(i)) But with this being a very common scenario for such a feature being needed, we'd see a lot of confusion with how much that looks like a walrus operator. I am +1 on the feature, but -1 on the syntax. On Thu, Apr 16, 2020 at 12:45 PM Steven D'Aprano wrote: > Do any other languages already have this feature? > > Can you show some actual real-life code that would benefit from this, as > opposed to pretend code like: > > foo(bar=, qux=) > > I think that if I had seen this syntax as a beginner, I would have had > absolutely no idea how to interpret it. I probably would have decided > that Python was an unreadably cryptic language and gone on to learn > something else. > > Of course, with 20+ years of experience reading and writing code, I > know better now. I would interpret it as setting bar and qux to some > kind of Undefined value. > > I am very sympathetic to the rationale: > > "it is quite common to find code that forwards keyword parameters having > to re-state keyword arguments names" > > and I've discussed similar/related issues myself, e.g. here: > > https://mail.python.org/pipermail/python-list/2018-February/881615.html > > But I am not convinced that adding magic syntax to implicitly guess the > value wanted as argument if it happens to match the parameter name is a > good design feature. > > Is being explicit about the value that you are passing to a parameter > really such a burden that we need special syntax to avoid stating what > value we are using as the argument? > > I don't think it is. And I would far prefer to read explicit code like > this: > > # Slightly modified from actual code. > self.do_something( > meta=meta, > dunder=dunder, > private=private, > invert=invert, > ignorecase=ignorecase, > ) > > over the implicit version: > > # Looks like code I haven't finished writing :-( > self.do_something(meta=, dunder=, private=, invert=, ignorecase=) > > > Out of the millions of possible values we might pass, I don't think that > the func(spam=spam) case is so special that we want to give it special > syntax. > > -- > Steven > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/VCCQ6BOVEQZ4ZWLKVDTVUCMAWD2VQL7B/ > Code of Conduct: http://python.org/psf/codeofconduct/ > > -- CALVIN SPEALMAN SENIOR QUALITY ENGINEER cspea...@redhat.com M: +1.336.210.5107 [image: https://red.ht/sig] <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted> ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/GXB6KYUUO2QKCYIDBYIV74GVZTRSQUSU/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Traits
On Fri, Feb 7, 2020 at 12:02 PM Soni L. wrote: > > > > On 2020-02-07 1:33 p.m., Nick Timkovich wrote: > > On Fri, Feb 7, 2020 at 10:11 AM Soni L. wrote: >> >> I'd like to see traits some day, with a syntax similar to this one: >> ... >> if the trait isn't used in the function definition you get the raw >> object, where name conflicts between traits (but not between traits and >> inherent methods) result in an error about name conflicts. otherwise you >> get a friendly wrapper. > > > I assume traits are a feature of another language, but not being familiar > with it can you illustrate its need a bit better? Can you give an example in > current Python, and how it could be made more clear with the notional trait > syntax? > > Nick > > > Hello Nick! > > Traits are an alternative to Multiple Inheritance. They solve the problem of > name conflicts by making them an ambiguity error and requiring you to > disambiguate (at call site). The examples shown seem to create the very problem you claim traits solve. It is only the introduction of your `impl` keyword in the example that allowed there to be more than one `x()` in the first place. Can you elaborate on why this is even a problem in the first place that would need solved in Python code today? > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/KFTJ6QRCTICL4NDUURNY35D7JIDM3VWY/ > Code of Conduct: http://python.org/psf/codeofconduct/ -- CALVIN SPEALMAN SENIOR QUALITY ENGINEER cspea...@redhat.com M: +1.336.210.5107 TRIED. TESTED. TRUSTED. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/XFJECACU55QMCRFYWPREG57OFJKPS5BC/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: addition of "nameof" operator
Why? That looks like more code to accomplish exactly the same thing.
On Tue, Jan 21, 2020 at 1:49 PM Johan Vergeer
wrote:
> I have worked with both C# and Python for a while now and there is one
> feature of C# I'm missing in the Python language.
>
> This feature is the "nameof" operator. (
> https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/operators/nameof
> ).
> The place I use this the most in C# is in `ToString()` methods or logging
> messages.
> This makes sure the developer cannot forget to update the name of a member.
>
> As an example I created this `Person` class.
>
> ```
> class Person:
> def __init__(self, name, age):
> self.name = name
> self.age = age
>
> def __repr__(self):
> return f"Person(name: {self.name}, age: {self.age})"
> ```
>
> With the `nameof` operator this would look like the following:
>
> ```
> class Person:
> def __init__(self, name, age):
> self.name = name
> self.age = age
>
> def __repr__(self):
> return f"{nameof(Person)}({nameof(self.name)}: {self.name},
> {nameof(self.age)}: {self.age})"
> ```
>
> What do you think about this?
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/UUFFAI3FZMQRVPDCUPZEOAZCRNXKWFDE/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
>
--
CALVIN SPEALMAN
SENIOR QUALITY ENGINEER
cspea...@redhat.com M: +1.336.210.5107
[image: https://red.ht/sig] <https://red.ht/sig>
TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/JD4NNVVHUZGUJXLG7C7V2YYR3VQELO2I/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP: add a `no` keyword as an alias for `not`
I think they actually read like they would mean slightly different things, which would make them existing as aliases confusing. I read `if not val` as "If val isn't true" but i would read `if no val` as "if val does not exist" On Thu, Aug 1, 2019 at 4:07 PM Daniel Okey-Okoro wrote: > I think that adding a `no` keyword as an alias for `not` would make for > more readable, simple, pythonic code. > > Take the below: > > ``` > if not val: > do_thing_because_value_is_falsy() > ``` > > could be (is actually understood as): > > ``` > if no val: >do_thing_because_value_is_falsy() > ``` > > I think this PEP is a work-around for an underlying subtle issue with how > the `not` operator is used. > > It has two use-cases: > > 1. as a NOT gate for producing opposite boolean values > > ``` > opposite = not regular > ``` > > 2. as a sort of ".is_falsy()" checker; when used with an if statement. > > like the first example. > > > This PEP would make the difference between the two usecases explicit. > > Thoughts? > > Best Intentions, > Daniel Okey-Okoro. > -- > https://mail.python.org/mailman/listinfo/python-list > -- CALVIN SPEALMAN SENIOR QUALITY ENGINEER cspea...@redhat.com M: +1.336.210.5107 [image: https://red.ht/sig] <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted> ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/KYKAPXVW74CGTUJRBPHOKZ6ILRD6A6VE/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Namespace context managers
Let's say you do this or any of the variants suggested... What does this do?
a = {"foo": 1}
b = {}
with a:
with b:
foo = 0
On Fri, Jul 26, 2019 at 3:20 AM Batuhan Taskaya
wrote:
> I am proposing namespace context managers with implementing `__enter__`
> and `__exit__` on dict objects. It would make closures possible in python
> with a pythonic syntax.
>
> a = 4
> namespace = {}
>
> with namespace:
> a = 3
>
> assert a == 4
> assert namespace["a"] == 3
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/TAVHEKDZVYKJUGZKWSVZVAOGBPLZVKQG/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
--
CALVIN SPEALMAN
SENIOR QUALITY ENGINEER
cspea...@redhat.com M: +1.336.210.5107
[image: https://red.ht/sig] <https://red.ht/sig>
TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/WIXNCWAEKSOUP6IY7CPCY6TOUJJSTDOP/
Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Add output() helper function to subprocess module
This is probably the most common first use case someone has when trying to use subprocess for the first time and I think it has always been a bit of a wart that, given all the helpers and wrappers the subprocess module already has, it lacks one for that very obvious and common need. Yes, run() covers everything, but so does subprocess.Popen() itself. Helpers still help. On Thu, Apr 4, 2019 at 1:15 PM Guido van Rossum wrote: > Let’s please leave this alone. As Serhiy says run() covers everything. > > On Thu, Apr 4, 2019 at 3:03 AM Oleg Broytman wrote: > >> On Thu, Apr 04, 2019 at 07:44:29PM +1100, Chris Angelico < >> ros...@gmail.com> wrote: >> > On Thu, Apr 4, 2019 at 7:12 PM Nathaniel Smith wrote: >> > > >> > > On Thu, Apr 4, 2019 at 12:48 AM Greg Ewing < >> greg.ew...@canterbury.ac.nz> wrote: >> > > > >> > > > The check_output() function of the subprocess module raises an >> > > > exception if the process returns a non-zero exit status. This is >> > > > inconvenient for commands such as grep that use the return >> > > > status to indicate something other than success or failure. >> > > > >> > > > The check_call() function has a companion call(), but here is >> > > > currently no non-checking companion for check_call(). How >> > > > about adding one with a signature such as >> > > > >> > > > output(args) --> (status, output) >> > > >> > > Isn't this already available as: run(args, stdout=PIPE)? Is the object >> > > to the extra typing, or...? >> > > >> > >> > Or discoverability. If you want to run a subprocess and catch its >> > output, you'll naturally reach for check_output, and it feels clunkier >> > to have to use run() instead. >> > >> > +1 on adding a nice simple function, although I'm not 100% sold on the >> > name "output". >> >>get_output ? >> >> > ChrisA >> >> Oleg. >> -- >> Oleg Broytmanhttps://phdru.name/ >> p...@phdru.name >>Programmers don't die, they just GOSUB without RETURN. >> _______ >> Python-ideas mailing list >> Python-ideas@python.org >> https://mail.python.org/mailman/listinfo/python-ideas >> Code of Conduct: http://python.org/psf/codeofconduct/ >> > -- > --Guido (mobile) > ___ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -- CALVIN SPEALMAN SENIOR QUALITY ENGINEER cspea...@redhat.com M: +1.336.210.5107 <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted> ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] PEP-582 and multiple Python versions
OK, I didn't know if this or -dev was more appropriate, so I opted on the safer side in terms of annoying people. I'll post to python-dev. On Mon, Apr 1, 2019 at 2:27 PM Brett Cannon wrote: > I just wanted to warn people that I don't know if any of the authors of > PEP 582 subscribe to python-ideas and they have not brought it forward for > discussion yet, so there's no guarantee of a response. > > On Mon, Apr 1, 2019 at 5:27 AM Calvin Spealman > wrote: > >> While the PEP does show the version number as part of the path to the >> actual packages, implying support for multiple versions, this doesn't seem >> to be spelled out in the actual text. Presumably __pypackages__/3.8/ might >> sit beside __pypackages__/3.9/, etc. to keep future versions capable of >> installing packages for each version, the way virtualenv today is bound to >> one version of Python. >> >> I'd like to raise a potential edge case that might be a problem, and >> likely an increasingly common one: users with multiple installations of the >> *same* version of Python. This is actually a common setup for Windows users >> who use WSL, Microsoft's Linux-on-Windows solution, as you could have both >> the Windows and Linux builds of a given Python version installed on the >> same machine. The currently implied support for multiple versions would not >> be able to separate these and could create problems if users pip install a >> Windows binary package through Powershell and then try to run a script in >> Bash from the same directory, causing the Linux version of Python to try to >> use Windows python packages. >> >> I'm not actually sure what the solution here is. Mostly I wanted to raise >> the concern, because I'm very keen on WSL being a great entry path for new >> developers and I want to make that a better experience, not a more >> confusing one. Maybe that version number could include some other unique >> identify, maybe based on Python's own executable. A hash maybe? I don't >> know if anything like that already exists to uniquely identify a Python >> build or installation. >> >> -- >> >> CALVIN SPEALMAN >> >> SENIOR QUALITY ENGINEER >> >> cspea...@redhat.com M: +1.336.210.5107 >> <https://red.ht/sig> >> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted> >> ___ >> Python-ideas mailing list >> Python-ideas@python.org >> https://mail.python.org/mailman/listinfo/python-ideas >> Code of Conduct: http://python.org/psf/codeofconduct/ >> > -- CALVIN SPEALMAN SENIOR QUALITY ENGINEER cspea...@redhat.com M: +1.336.210.5107 <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted> ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] PEP-582 and multiple Python versions
While the PEP does show the version number as part of the path to the actual packages, implying support for multiple versions, this doesn't seem to be spelled out in the actual text. Presumably __pypackages__/3.8/ might sit beside __pypackages__/3.9/, etc. to keep future versions capable of installing packages for each version, the way virtualenv today is bound to one version of Python. I'd like to raise a potential edge case that might be a problem, and likely an increasingly common one: users with multiple installations of the *same* version of Python. This is actually a common setup for Windows users who use WSL, Microsoft's Linux-on-Windows solution, as you could have both the Windows and Linux builds of a given Python version installed on the same machine. The currently implied support for multiple versions would not be able to separate these and could create problems if users pip install a Windows binary package through Powershell and then try to run a script in Bash from the same directory, causing the Linux version of Python to try to use Windows python packages. I'm not actually sure what the solution here is. Mostly I wanted to raise the concern, because I'm very keen on WSL being a great entry path for new developers and I want to make that a better experience, not a more confusing one. Maybe that version number could include some other unique identify, maybe based on Python's own executable. A hash maybe? I don't know if anything like that already exists to uniquely identify a Python build or installation. -- CALVIN SPEALMAN SENIOR QUALITY ENGINEER cspea...@redhat.com M: +1.336.210.5107 <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted> ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Left arrow and right arrow operators
I don't like the idea of arrows in both directions when you can just swap
the operands instead
On Sun, Mar 3, 2019 at 9:52 AM francismb wrote:
> Hi,
> the idea here is just to add the __larrow__ and __rarrow__ operators for
> <- and ->.
>
>
> E.g. of use on dicts :
> >>> d1 = {'a':1, 'b':1 }
> >>> d2 = {'a':2 }
> >>> d3 = d1 -> d2
> >>> d3
> {'a':1, 'b':1 }
>
> >>> d1 = {'a':1, 'b':1 }
> >>> d2 = {'a':2 }
> >>> d3 = d1 <- d2
> >>> d3
> {'a':2, 'b':1 }
>
> Or on bools as Modus Ponens [1]
>
> Or your idea/imagination here :-)
>
>
>
> Regards,
> --francis
>
> [1] https://en.wikipedia.org/wiki/Modus_ponens
>
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
--
CALVIN SPEALMAN
SENIOR QUALITY ENGINEER
cspea...@redhat.com M: +1.336.210.5107
<https://red.ht/sig>
TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Potential PEP: with/except
On Tue, Jan 22, 2019 at 3:11 PM Paul Ferrell wrote:
> I've found that almost any time I'm writing a 'with' block, it's doing
> something that could throw an exception. As a result, each of those
> 'with' blocks needs to be nested within a 'try' block. Due to the
> nature of 'with', it is rarely (if ever) the case that the try block
> contains anything other than the with block itself.
>
> As a result, I would like to propose that the syntax for 'with' blocks
> be changed such that they can be accompanied by 'except', 'finally',
> and/or 'else' blocks as per a standard 'try' block. These would handle
> exceptions that occur in the 'with' block, including the execution of
> the applicable __enter__ and __exit__ methods.
>
> Example:
>
> try:
> with open(path) as myfile:
> ... # Do stuff with file
> except (OSError, IOError) as err:
> logger.error("Failed to read/open file {}: {}".format(path, err)
>
> The above would turn into simply:
>
> with open(path) as myfile:
> ... # Do stuff with file
> except (OSError, IOError) as err:
> logger.error(...)
>
>
It definitely makes sense, both the problem and the proposed solution.
The thing that concerns me is that any such problem and solution seems
to apply equally to any other kind of block. Why not allow excepts on fo
loops, for example?
>
> I think this is rather straightforward in meaning and easy to read,
> and simplifies some unnecessary nesting. I see this as the natural
> evolution of what 'with'
> is all about - replacing necessary try-finally blocks with something
> more elegant. We just didn't include the 'except' portion.
>
> I'm a bit hesitant to put this out there. I'm not worried about it
> getting shot down - that's kind of the point here. I'm just pretty
> strongly against to unnecessary syntactical additions to the language.
> This though, I think I can except. It introduces no new concepts and
> requires no special knowledge to use. There's no question about what
> is going on when you read it.
>
> --
> Paul Ferrell
> pfl...@gmail.com
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
--
CALVIN SPEALMAN
SENIOR QUALITY ENGINEER
cspea...@redhat.com M: +1.336.210.5107
<https://red.ht/sig>
TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Backtick expression: similar to a shorter lambda syntax
On Sun, Jan 20, 2019 at 9:43 PM James Lu wrote: > Backtick expressions work exactly like lambdas, except that they are bound > to the instance they are created in every time that class is used to create > one. To illustrate, this “percent” property is bound to the instance, not > to the class. > class Example: > percent = property(`self.v*self.v2/100`) > > And a few more examples for clarity. > > def example(): > locals()['a'] = 1 > expr = `a+1` > return expr() # error: one variable is required > > Any variable names that exist when the backtick expression is created are > bound to the expression, and the reference to the expression is stored > within the expression. Names that do not exist when the expresssion is > created must be passed in as parameters. Such names can also be passed in > as keyword arguments. Backtick expressions are created when their scope is > created. > > Variable names that are declared but have not been assigned to will be > considered to exist for the purposes of the backtick expression. > > Directly calling a backtick expression as soon as it’s created is > forbidden: > > `v+1`(a) > > But this is technically allowed but discouraged, like how := works: > (`v+1`)(a) > > Use Cases > > This can be used anywhere a lambda would feel “heavy” or long. Here are a > few use cases where using a backtick expression would allow code to be > significantly mote readable: > > If/else chains that would be switch statements. > Creating decorators. > Passing in logging hooks. > Writing design-by-contract contracts. (See icontract on GitHub for an > example of what DBC looks like in Python.) > Tests and assertions. > > Additionally, the instance binding enables: > > A shorthand way to create a class that wraps an API to a better or more > uniform code interface. Previously you’d need to make defs and @property, > now each wrapped property and method is a single, readable line of code. > > Appendix > > I propose syntax highlighters show a backtick expression on a different > background color, a lighter shade of black for a dark theme; dirty white > for a light thing. > > I also propose the following attributes on the backtick expression. > > __str__(): the string [parameter names separated by commas] => [the string > of the backtick expression] > __repr__(): the original string of the backtick expression, surrounded by > backticks. > > I secondarily propose that backtick expressions are only bound to their > instances when defined within a class when the following syntax is used: > > def a = > > — > Now, let’s bikeshed. > I don't overall hate the idea, but I do have a few negatives to list I see. 1) While backticks are a free syntax now, they used to be a repr() expression in older versions of Python! I'm not keen on re-using them, it'll look real weird to us old people who remember that being common. 2) As a syntax it is pretty lightweight and could be easy to overlook. I like that you thought of highlighters, but you can't depend on them to make this syntax easier to notice. Instead, it is likely that the expressions in the backticks will just blend in with the rest of the code around them. The one positive I see is that because there is no open and closing pair of backticks, like parens or brackets, you can't easily nest this syntax and I actually like how it inherently discourages or makes that impossible! I can't say if I'm -0 or +0 but it is one of those. > _______ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -- CALVIN SPEALMAN SENIOR QUALITY ENGINEER cspea...@redhat.com M: +1.336.210.5107 <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted> ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Serialization of CSV vs. JSON
First, this list is not appropriate. You should ask such a question in python-list. Second, JSON is a specific serialization format that explicitly rejects datetime objects in *all* the languages with JSON libraries. You can only use date objects in JSON if you control or understand both serialization and deserialization ends and have an agreed representation. On Fri, Nov 2, 2018 at 12:20 PM Philip Martin wrote: > Is there any reason why date, datetime, and UUID objects automatically > serialize to default strings using the csv module, but json.dumps throws an > error as a default? i.e. > > import csv > import json > import io > from datetime import date > > stream = io.StringIO() > writer = csv.writer(stream) > writer.writerow([date(2018, 11, 2)]) > # versus > json.dumps(date(2018, 11, 2)) > > ___ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Allow Context Managers to Support Suspended Execution
I'm very curious about the idea, but can't come up with any use cases based just one your explanation. Maybe you could give some examples where this would be useful? In particular, what are some cases that are really hard to handle now and how would those cases be improved like this? On Wed, Oct 31, 2018 at 10:53 PM David Allemang wrote: > I do not think there is currently a good way for Context Managers to > support suspended execution, as in await or yield. Both of these > instructions cause the interpreter to leave the with block, yet no > indication of this (temporary) exit or subsequent re-entrance is given > to the context manager. If the intent of a Context Manager is to say > "no matter how this block is entered or exited, the context will be > correctly maintained", then this needs to be possible. > > I would propose magic methods __suspend__ and __resume__ as companions > to the existing __enter__ and __exit__ methods (and their async > variants). __suspend__, if present, would be called upon suspending > execution on an await or yield statement, and __resume__, if present, > would be called when execution is resumed. If __suspend__ or > __resume__ are not present then nothing should be done, so that the > behavior of existing context managers is preserved. > > Here is an example demonstrating the issue with await: > https://gist.github.com/allemangD/bba8dc2d059310623f752ebf65bb6cdc > and one with yield: > https://gist.github.com/allemangD/f2534f16d3a0c642c2cdc02c544e854f > > The context manager used is clearly not thread-safe, and I'm not > actually sure how to approach a thread-safe implementation with the > proposed __suspend__ and __resume__ - but I don't believe that > introducing these new methods would create any issues that aren't > already present with __enter__ and __exit__. > > It's worth noting that the context manager used in those examples is, > essentially, identical contextlib's redirect_stdout and decimal's > localcontext managers. Any context manager such as these which modify > global state or the behavior of global functions would benefit from > this. It may also make sense to, for example, have the __suspend__ > method on file objects flush buffers without closing the file, similar > to their current __exit__ behavior, but I'm unsure what impact this > would have on performance. > > It is important, though, that yield and await not use __enter__ or > __exit__, as not all context-managers are reusable. I'm unsure what > the best term would be to describe this type of context, as the > documentation for contextlib already gives a different definition for > "reentrant" - I would then call them "suspendable" contexts. It would > make sense to have an @suspendable decorator, probably in contextlib, > to indicate that a context manager can use __enter__ and __exit__ > methods rather than __suspend__ and __resume__. All it would need to > do is define __suspend__ to call __enter__() and __resume__ to call > __exit__(None, None, None). > > It is also important, since __suspend__ and __resume__ would be called > after a context is entered but before it is exited, that __suspend__ > not accept any parameters and that __resume__ not use its return > value. __suspend__ could not be triggered by an exception, only by a > yield or await, and __resume__ could not have its return value named > with as. > > Thanks, > > David > ___ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Return for assignment blocks
On Thu, Oct 25, 2018 at 9:28 AM Anders Hovmöller wrote: > > > The point is not saving a line or typing, but saving a thought. > Expressing the intent of the factory function more clearly. > > Could you give some other usage examples? > > To me it seems like a nicer and less confusing way to create decorators is > warranted but could then be more specialized and this much nicer. We > wouldn't necessarily get to that future point by adding super tiny > improvements to what we have, but instead take a step back and rethink what > the syntax could be. Personally I often just copy paste an existing > decorator and then tweak it instead of writing from scratch because it's > too confusing and error prone to do that. > You know what, I *can't* think of other good examples than slightly improved decorators. So, maybe its not that great an idea if it can't be applied to at least a few more use cases. / Anders ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Return for assignment blocks
On Wed, Oct 24, 2018 at 4:41 PM Steven D'Aprano wrote: > On Wed, Oct 24, 2018 at 09:18:14AM -0400, Calvin Spealman wrote: > > I'd like to suggest what I think would be a simple addition to `def` and > > `class` blocks. I don't know if calling those "Assignment Blocks" is > > accurate, but I just mean to refer to block syntaxes that assign to a > name. > > Anyway, I propose a combined return-def structure, and optionally also > > allowing a return-class version. Omitting the name would be allowable, as > > well. > > > > This would only apply to a `def` or `class` statement made as the last > part > > of the function body, of course. > > > > def ignore_exc(exc_type): > > return def (func): > > @wraps(func) > > return def (*args, **kwargs): > > try: > > return func(*args, **kwargs) > > except exc_type: > > pass > > Your example is too complex for me this early in the morning -- I can't > tell what it actually *does*, as it is obscured by what looks like a > bunch of irrelevent code. > > I *think* you are proposing the following syntax. Am I right? > > > return def (func): > # body of func > > which is equivalent to: > > def func: > # body of func > return func > > And similar for classes: > > return class (K): > # body of K > > being equivalent to: > > class K: > # body of K > return K > > > Is it intentional that your example function takes no arguments? If the > function did, where would the parameter list go in your syntax? > > Aside from saving one line, what is the purpose of this? > The point is not saving a line or typing, but saving a thought. Expressing the intent of the factory function more clearly. Decorators don't do more than "saving one line", either. But the biggest reason I'd like something like this is that it solves a *specific* version of the multi-line anonymous function that comes up over and over and over again, and maybe by chipping away at those use-cases we can stop seeing *that* debate over and over and over again. :-) So, no, it doesn't save a lot of typing, but I'm never interested in that. I don't spend a lot of time typing code, I spend it reading code, and something like this would certainly help there, imho. > -- > Steve > ___ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Return for assignment blocks
My idea is not "assignment blocks" those already exist. `def` and `class`
blocks are both syntaxes that assign to some name. I'm just using the term
to refer to them as a group.
The proposal is just being able to return them. These two examples become
equivalent:
def ignore_exc(exc_type):
return def (func):
@wraps(func)
return def (*args, **kwargs):
try:
return func(*args, **kwargs)
except exc_type:
pass
def ignore_exc(exc_type):
def decorator(func):
@wraps(func)
def wrapped_func(*args, **kwargs):
try:
return func(*args, **kwargs)
except exc_type:
pass
return wrapped_func
return decorator
On Wed, Oct 24, 2018 at 9:51 AM Benedikt Werner <1benediktwer...@gmail.com>
wrote:
> Would you mind providing a bit more details about your proposal?
>
> What exactly are those "Assignment Blocks" supposed to do?
>
> If I understand your proposal correctly you want this:
>
> def my_func():
> return def():
> print("abc")
>
> to be the same as this:
>
> def my_func():
> def inner_func():
> print("abc")
> return inner_func
>
> But this is only my assumption as your proposal doesn't give very much
> details.
> Maybe you should provide a few simple examples and explain what they are
> supposed to do or what they should be equivalent to.
>
> Your example is quite complex and to me it's not clear at all what it is
> supposed to mean.
>
> Also and probably most importantly what is the reason you want this? Are
> there any good usecases where this would help?
>
> If my assumption above is correct this just looks like a bit of syntactic
> sugar that IMO isn't really neccessary. It doesn't really improve
> readability or save many characters. The existing way to do this is totally
> fine.
>
> Benedikt
>
> Am 24.10.2018 um 15:18 schrieb Calvin Spealman:
>
> I'd like to suggest what I think would be a simple addition to `def` and
> `class` blocks. I don't know if calling those "Assignment Blocks" is
> accurate, but I just mean to refer to block syntaxes that assign to a name.
> Anyway, I propose a combined return-def structure, and optionally also
> allowing a return-class version. Omitting the name would be allowable, as
> well.
>
> This would only apply to a `def` or `class` statement made as the last
> part of the function body, of course.
>
> def ignore_exc(exc_type):
> return def (func):
> @wraps(func)
> return def (*args, **kwargs):
> try:
> return func(*args, **kwargs)
> except exc_type:
> pass
>
> Thanks for considering and for any comments, thoughts, or feedback on the
> idea!
>
>
> ___
> Python-ideas mailing
> listPython-ideas@python.orghttps://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Return for assignment blocks
I'd like to suggest what I think would be a simple addition to `def` and `class` blocks. I don't know if calling those "Assignment Blocks" is accurate, but I just mean to refer to block syntaxes that assign to a name. Anyway, I propose a combined return-def structure, and optionally also allowing a return-class version. Omitting the name would be allowable, as well. This would only apply to a `def` or `class` statement made as the last part of the function body, of course. def ignore_exc(exc_type): return def (func): @wraps(func) return def (*args, **kwargs): try: return func(*args, **kwargs) except exc_type: pass Thanks for considering and for any comments, thoughts, or feedback on the idea! ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Add .= as a method return value assignment operator
Absolutely -1 on this. Consider the following example:
def encode(s, *args):
"""Force UTF 8 no matter what!"""
return s.encode('utf8')
text = "Hello, there!"
text .= encode('latin1')
Do you see how this creates an ambiguous situation? Implicit attribute
lookup like this is really confusing. It reminds me of the old `with`
construct in javascript that is basically forbidden now, because it created
the same situation.
On Thu, Sep 27, 2018 at 6:49 AM Ken Hilton wrote:
> Hi Jasper,
> This seems like a great idea! It looks so much cleaner, too.
>
> Would there be a dunder method handling this? Or since it's explicitly
> just a syntax for "obj = obj.method()" is that not necessary?
> My only qualm is that this might get PHP users confused; that's really not
> an issue, though, since Python is not PHP.
>
> Anyway, I fully support this idea.
>
> Sincerely,
> Ken Hilton;
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Retire or reword the namesake of the Language
I am very disappointed in the existence of this thread. Mocking discourse is extremely unpythonic. On Mon, Sep 17, 2018 at 2:54 AM Jacco van Dorp wrote: > Yeah, sounds about as sensible as the recent "ban ugly" campaign. > +1. > > Op zo 16 sep. 2018 om 15:49 schreef Wes Turner : > >> Anyways, speaking of dragons, here are some ideas for new logos: >> >> "Strong Bad Email #58: Dragon" >> https://youtu.be/90X5NJleYJQ >> >> https://en.wikipedia.org/wiki/Monty_Python >> >> On Sunday, September 16, 2018, Wes Turner wrote: >> >>> There's already a thing named Cobra. >>> >>> https://github.com/opencobra/cobrapy >>> >>> >>> "Python (mythology)" >>> https://en.wikipedia.org/wiki/Python_(mythology) >>> ... Serpent/Dragon guarding the omphalos. >>> >>> "Ouroboros" >>> https://en.wikipedia.org/wiki/Ouroboros >>> >>> >>> Monty Python themed Python language things: >>> >>> - The Cheese Shop >>> https://en.wikipedia.org/wiki/Cheese_Shop_sketch >>> https://wiki.python.org/moin/CheeseShop >>> https://pypi.org/ >>> >>> - The Knights Who Say Ni -- >>> https://en.wikipedia.org/wiki/Knights_Who_Say_Ni >>> https://github.com/python/the-knights-who-say-ni >>> >>> - Miss Islington >>> https://github.com/python/miss-islington >>> >>> On Sunday, September 16, 2018, Chris Angelico wrote: >>> On Sun, Sep 16, 2018 at 8:14 PM, Widom PsychoPath wrote: > I hereby propose that the Language should be renamed to Cobra, after > the brilliant military strategist Cobra Commander , who has been > history's most efficient and brilliant strategist. > > Yours forever, > Jack Daniels Now THAT is the *true* spirit of professionalism. Here we have proof that the scientific community cares about the language. About 80 proof, I think. ChrisA ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/ >>> ___ >> Python-ideas mailing list >> Python-ideas@python.org >> https://mail.python.org/mailman/listinfo/python-ideas >> Code of Conduct: http://python.org/psf/codeofconduct/ >> > ___ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Retire or reword the "Beautiful is better than ugly" Zen clause
Samantha, I came into this thread reading the subject and thinking "over my dead body!" until I read your well-thought reasoning and gave even a little bit of thought to the idea. You're absolutely right and while I think its very unlikely to get enough support I do think it is a very good suggestion, totally reasonable, and that we *should* change it. I ask everyone on this thread being rude to please step back and try to look at the issue without your bias and knee-jerk reactions. Even if you can't change your minds, at least be more civil about it. On Thu, Sep 13, 2018 at 4:38 AM Samantha Quan wrote: > First, I'd like to express how grateful I am to see more and more > technical communities embrace diversity and inclusivity, particularly big > tech communities like Python, Redis, and Django. > > In the spirit of the big recent terminology change, I propose retiring or > rewording the "Beautiful is better than ugly" Zen clause for perpetuating > beauty bias and containing lookist slur. I realize that Zen is old, but you > can't argue that the word "ugly" is harmless, now that society condemns > body shaming, and instead promotes body acceptance and self-love. One > alternative to that clause I could think of is "Clean is better than > dirty", but please do speak up if you have better ideas. > > I ask you to give this change serious consideration, even if it seems > over-the-top to you now, because times change, and this will be of great > help in the battle for the more tolerant and less judgemental society. > > I understand that this topic may seem controversial to some, so please be > open-minded and take extra care to respect the PSF Code Of Conduct when > replying. > > Thank you! > > - Sam > > Some references: > > https://www.urbandictionary.com/define.php?term=Lookism > https://en.m.wikipedia.org/wiki/Lookism > ___ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Keyword only argument on function call
On Thu, Sep 6, 2018 at 9:11 AM Steven D'Aprano wrote: > On Thu, Sep 06, 2018 at 12:15:46PM +0200, Anders Hovmöller wrote: > > > I have a working implementation for a new syntax which would make > > using keyword arguments a lot nicer. Wouldn't it be awesome if instead > > of: > > > > foo(a=a, b=b, c=c, d=3, e=e) > > > > we could just write: > > > > foo(*, a, b, c, d=3, e) > > > > and it would mean the exact same thing? > > No. > > > > This would not just be shorter but would create an incentive for > > consistent naming across the code base. > > You say that as if consistent naming is *in and of itself* a good thing, > merely because it is consistent. > > I'm in favour of consistent naming when it helps the code, when the > names are clear and relevant. But why should I feel bad about failing to > use the same names as the functions I call? If some library author names > the parameter to a function "a", why should I be encouraged to use > that same name *just for the sake of consistency*? > I've been asking this same question on the Javascript/ES6 side of my work ever since unpacking was introduced there which baked hash-lookup into the unpacking at a syntax level. In that world its impacted this same encouragement of "consistency" between local variable names and parameters of called functions and it certainly seems popular in that ecosystem. The practice still feels weird to me and I'm on the fence about it. Although, to be honest, I'm definitely leaning towards the "No, actually, it is a good thing." I grew up, development-speaking, in the Python world with a strong emphasis drilled into me that style constraints make better code and maybe this is just an extension of that. Of course, you might not always want the same name, but it is only encouraged not required. You can always rename variables. That said... I'm not actually a fan of the specific suggested syntax: > foo(*, a, b, c, d=3, e) I just wanted to give my two cents on the name consistency issue. > > So the idea is to generalize the * keyword only marker from function > > to also have the same meaning at the call site: everything after * is > > a kwarg. With this feature we can now simplify keyword arguments > > making them more readable and concise. (This syntax does not conflict > > with existing Python code.) > > It's certainly more concise, provided those named variables already > exist, but how often does that happen? You say 30% in your code base. > > (By the way, well done for writing an analysis tool! I mean it, I'm not > being sarcastic. We should have more of those.) > > I disagree that f(*, page) is more readable than an explicit named > keyword argument f(page=page). > > My own feeling is that this feature would encourage what I consider a > code-smell: function calls requiring large numbers of arguments. Your > argument about being concise makes a certain amount of sense if you are > frequently making calls like this: > > # chosing a real function, not a made-up example > open(file, mode=mode, buffering=buffering, encoding=encoding, > errors=errors, newline=newline, closefd=closefd, opener=opener) > > If 30% of your function calls look like that, I consider it a > code-smell. > > The benefit is a lot smaller if your function calls look more like this: > > open(file, encoding=encoding) > > and even less here: > > open(file, 'r', encoding=self.encoding or self.default_encoding, > errors=self.errors or self.default_error_handler) > > for example. To get benefit from your syntax, I would need to > extract out the arguments into temporary variables: > > encoding = self.encoding or self.default_encoding > errors = self.errors or self.default_error_handler > open(file, 'r', *, encoding, errors) > > which completely cancels out the "conciseness" argument. > > First version, with in-place arguments: > 1 statement > 2 lines > 120 characters including whitespace > > Second version, with temporary variables: > 3 statements > 3 lines > 138 characters including whitespace > > > However you look at it, it's longer and less concise if you have to > create temporary variables to make use of this feature. > > > -- > Steve > ___ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Revisiting str.rreplace()
If its treated as a missing parameter, and currently doesn't do anything,
then it wouldn't be used... right? and it could be safe to add behavior for
it... right?
On Thu, Jul 19, 2018 at 11:17 AM, Eric V. Smith wrote:
> On 7/19/2018 10:01 AM, Calvin Spealman wrote:
>
>> As an alternative suggestion: What if the count parameter to
>> str.replace() counted from the right with negative values? That would be
>> consistent with other things like indexing and slicing.
>>
>
> We couldn't make this change because negative values already have a
> meaning: it's interpreted as a missing parameter:
>
> >>> 'abab'.replace('a', 'z')
> 'zbzb'
> >>> 'abab'.replace('a', 'z', 0)
> 'abab'
> >>> 'abab'.replace('a', 'z', 1)
> 'zbab'
> >>> 'abab'.replace('a', 'z', -1)
> 'zbzb'
> >>> 'abab'.replace('a', 'z', -2)
> 'zbzb'
> >>> 'abab'.replace('a', 'z', -100)
> 'zbzb'
>
> I think .rreplace() is the better design.
>
> Eric
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] PEP 505: None-aware operators: operators ?= and ?? and OR
The concatenated name reads a little weird. Alternatively, extend the conditional expression syntax. a = b if None c equivalent to a = b if b is None else c On Thu, Jul 19, 2018 at 9:35 AM, Robert Vanden Eynde wrote: > If we're about to use a new keyword, it could be infix too: > > a = b ifnone c > > Although the assignment version looks unusual: > > b ifnone= c > > Then with the "default b = c" would look like this: > > ifnone b = c > > Le jeu. 19 juil. 2018 à 15:30, Calvin Spealman a > écrit : > >> Operators that only vary by case would be... confusing. I'm not super >> keen on the other syntax (either the ?? or .? operators) but I do think >> they read well in C# where they come from. Different things work in >> different languages, some times. >> >> What about a new keyword: default >> >> So you'd write the above examples like this: >> >> default hi = len(a) # Only executes the assignment if the left-hand is >> None >> default encoding = sys.getdefaultencoding() >> >> On Thu, Jul 19, 2018 at 9:06 AM, Pål Grønås Drange > > wrote: >> >>> > I've started a subthread, just to discuss the ?= and ?? operators. And >>> > something newish, that I call OR. >>> >>> I would think `||` would be much better. >>> >>> It could be a kind of "semantic or" which could use the aforementioned >>> dunder has_value. >>> >>> -1, though, but to the general None-awareness. >>> >>> Pål >>> >>> ___ >>> Python-ideas mailing list >>> Python-ideas@python.org >>> https://mail.python.org/mailman/listinfo/python-ideas >>> Code of Conduct: http://python.org/psf/codeofconduct/ >>> >>> >> ___ >> Python-ideas mailing list >> Python-ideas@python.org >> https://mail.python.org/mailman/listinfo/python-ideas >> Code of Conduct: http://python.org/psf/codeofconduct/ >> > > ___ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > > ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Revisiting str.rreplace()
It would be consistent to apply it to other functions and I'd be in favour of that, yes. On Thu, Jul 19, 2018 at 10:06 AM, Eric Fahlgren wrote: > On Thu, Jul 19, 2018 at 7:01 AM Calvin Spealman > wrote: > >> As an alternative suggestion: What if the count parameter to >> str.replace() counted from the right with negative values? That would be >> consistent with other things like indexing and slicing. >> > > That could certainly be made to work, but I think it fails the > discoverability test. You'd have the [:]-syntax and replace working one > way, and split/rsplit, find/rfind and so on working another way. Unless > you're proposing the negative index for the latter ones also? > ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Revisiting str.rreplace()
As an alternative suggestion: What if the count parameter to str.replace() counted from the right with negative values? That would be consistent with other things like indexing and slicing. On Thu, Jul 19, 2018 at 9:47 AM, Eric Fahlgren wrote: > On Wed, Jul 18, 2018 at 8:20 PM Graham Gott com> wrote: > >> >> Thoughts? Support/oppose? >> > > > +1, along with an overall rework of str methods to make them more > consistent. > > The find, replace and split families should all gain the same > tuple-as-search-string that endswith and startswith use. (Discussed in the > last year, I'm too lazy to look up references...) > > > > ___ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > > ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] PEP 505: None-aware operators: operators ?= and ?? and OR
Operators that only vary by case would be... confusing. I'm not super keen on the other syntax (either the ?? or .? operators) but I do think they read well in C# where they come from. Different things work in different languages, some times. What about a new keyword: default So you'd write the above examples like this: default hi = len(a) # Only executes the assignment if the left-hand is None default encoding = sys.getdefaultencoding() On Thu, Jul 19, 2018 at 9:06 AM, Pål Grønås Drange wrote: > > I've started a subthread, just to discuss the ?= and ?? operators. And > > something newish, that I call OR. > > I would think `||` would be much better. > > It could be a kind of "semantic or" which could use the aforementioned > dunder has_value. > > -1, though, but to the general None-awareness. > > Pål > > ___ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > > ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
