[Python-ideas] Re: Can we give built-in `help` function a `__qualname__` attribute
The help function is not a built-in but an instance of a class defined in _sitebuiltins. Like other instances, it has neither __qualname__ nor __name__, but its __class__ does. On Fri, Apr 7, 2023 at 7:46 PM Samuel Muldoon wrote: > Hi, > > A lot of python's built-in functions have an attribute named __qualname__. > > However, the built-in `help` function has no __qualname__ attribute. > > In a future version of python can we have: > > help.__qualname__ = "help" > > ___ > 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/PKBVAC4M2LGIB55XT4WJPVOFFZGXJHHP/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ 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/RJSQTN6DK5GUHTYP2CSZV7FH45IHUC6X/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Ampersand operator for strings
I agree. This behavior is too specialized to be implemented as an
operator. + is IME so infrequently used on python strings that we should
take caution when proposing new binary string operators. Two strings to
concat, maybe; three, possibly; four or more, and I reach for join() or
f-strings or anything else. And if we are just joining two or three
strings, that is readable right now as str1.rstrip() + ' ' + str2.lstrip().
A solution that is as extensible as join, no need for operators or
subclasses:
def connect(iterable, /):
it = iter(iterable)
first = next(it, '')
last = next(it, None)
if last is None:
return first
else:
parts = [first.rstrip()]
for this in it:
parts.append(last.strip())
last = this
parts.append(last.lstrip())
return ' '.join(parts)
But I would not advocate for inclusion in the standard lib as there are too
many parameters the user may want to behave differently for them. Keep the
trailing spaces? Leading space? Add spaces when connecting an empty string?
A string that is only whitespace? Operate only on exactly str or the
__str__ value of any object?
Regards,
Jeremiah
On Tue, Mar 7, 2023 at 1:57 AM Valentin Berlier wrote:
> I'm -1 on this. You can easily make a helper that achieves the desired
> syntax. Presenting "human readable data" isn't just about collapsing
> spaces, and having your own helper means that you can adjust the formatting
> to your specific use case if needed (for example with a different
> separator).
>
> from typing import Self
>
> class StripJoin:
> def __init__(self, value: str = "") -> None:
> self.value = value
> def __and__(self, other: str) -> Self:
> other = other.strip()
> separator = bool(self.value and other) * " "
> return StripJoin(f"{self.value}{separator}{other}")
> def __str__(self) -> str:
> return self.value
>
> j = StripJoin()
> print(j & " foo " & " bar " & " something ")
> # Output: "foo bar something"
>
> The example above is more efficient than a possible implementation
> directly on the str builtin as it doesn't strip the left side over and
> over. However it still incurs repeated allocations and encourages a pattern
> that performs badly in loops. With a lot of input you should probably
> accumulate the stripped strings in a list and join them all at once.
>
> In any case I recommend reaching out for a library like Rich (
> https://github.com/Textualize/rich) if you care about formatting the
> output of your program nicely.
> ___
> 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/A7RPR3FSBXEMRYAUXJVYYROCHVHL7DVP/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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/WBNVDT52YHGD5PKJKE26RXAOLEZRN6I7/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Idea: Tagged strings in python
That's interesting, for me both 3.9 and 3.10 show the f-string more than 5x
faster.
This is just timeit on f'{myvar}' vs ''.join((myvar,)) so it may not be the
most nuanced
comparison for a class property.
Probably unsurprisingly having myvar be precomputed as the single tuple also
gives speedups, around 45% for me. So if just speed is wanted maybe inject
the
tuple pre-constructed.
~ Jeremiah
On Wed, Dec 21, 2022 at 1:19 AM Steven D'Aprano wrote:
> On Tue, Dec 20, 2022 at 11:55:49PM -0800, Jeremiah Paige wrote:
> > @property
> > def data(self):
> > return f"{self}"
>
> By my testing, on Python 3.10, this is slightly faster still:
>
> @property
> def data(self):
> return "".join((self,))
>
> That's about 14% faster than the f-string version.
>
> ___
> 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/CCZG6ALFEV3B67LENW5ZDJG5XSHKREG4/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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/KUNHKJJJTSXNSJRBTGZNIA2TGYM5OE7O/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Idea: Tagged strings in python
@property
def data(self):
return f"{self}"
Not at a workstation but this should be faster than join() while still
using syntax and not builtin functions.
~ Jeremiah
On Tue, Dec 20, 2022 at 5:38 PM Christopher Barker
wrote:
> As has been said, a builtin *could* be written that would be "friendly to
> subclassing", by the definition in this thread. (I'll stay out of the
> argument for the moment as to whether that would be better)
>
> I suspect that the reason str acts like it does is that it was originally
> written a LONG time ago, when you couldn't subclass basic built in types at
> all.
>
> Secondarily, it could be a performance tweak -- minimal memory and peak
> performance are pretty critical for strings.
>
> But collections.UserString does exist -- so if you want to subclass, and
> performance isn't critical, then use that. Steven A pointed out that
> UserStrings are not instances of str though. I think THAT is a bug. And
> it's probably that way because with the magic of duck typing, no one cared
> -- but with all the static type hinting going on now, that is a bigger
> liability than it used to be. Also basue when it was written, you couldn't
> subclass str.
>
> Though I will note that run-time type checking of string is relatively
> common compared to other types, due to the whole a-str-is-a-sequence-of-str
> issue making the distinction between a sequence of strings and a string
> itself is sometimes needed. And str is rarely duck typed.
>
> If anyone actually has a real need for this I'd post an issue -- it'd be
> interesting if the core devs see this as a bug or a feature (well, probably
> not feature, but maybe missing feature)
>
> OK -- I got distracted and tried it out -- it was pretty easy to update
> UserString to be a subclass of str. I suspect it isn't done that way now
> because it was originally written because you could not subclass str -- so
> it stored an internal str instead.
>
> The really hacky part of my prototype is this:
>
> # self.data is the original attribute for storing the string internally.
> Partly to prevent my having to re-write all the other methods, and partly
> because you get recursion if you try to use the methods on self when
> overriding them ...
>
> @property
> def data(self):
> return "".join(self)
>
> The "".join is because it was the only way I quickly thought of to make a
> native string without invoking the __str__ method and other initialization
> machinery. I wonder if there is another way? Certainly there is in C, but
> in pure Python?
>
> Anyway, after I did that and wrote a __new__ -- the rest of it "just
> worked".
>
> def __new__(cls, s):
> return super().__new__(cls, s)
>
> UserString and its subclasses return instances of themselves, and
> instances are instances of str.
>
> Code with a couple asserts in the __main__ block enclosed.
>
> Enjoy!
>
> -CHB
>
> NOTE: VERY minimally tested :-)
>
> On Tue, Dec 20, 2022 at 4:17 PM Chris Angelico wrote:
>
>> On Wed, 21 Dec 2022 at 09:30, Cameron Simpson wrote:
>> >
>> > On 19Dec2022 22:45, Chris Angelico wrote:
>> > >On Mon, 19 Dec 2022 at 22:37, Steven D'Aprano
>> wrote:
>> > >> > But this much (say with a better validator) gets you static type
>> checking,
>> > >> > syntax highlighting, and inherent documentation of intent.
>> > >>
>> > >> Any half-way decent static type-checker will immediately fail as
>> soon as
>> > >> you call a method on this html string, because it will know that the
>> > >> method returns a vanilla string, not a html string.
>> > >
>> > >But what does it even mean to uppercase an HTML string? Unless you
>> > >define that operation specifically, the most logical meaning is
>> > >"convert it into a plain string, and uppercase that".
>> >
>> > Yes, this was my thought. I've got a few subclasses of builtin types.
>> > They are not painless.
>> >
>> > For HTML "uppercase" is a kind of ok notion because the tags are case
>> > insensitive.
>>
>> Tag names are, but their attributes might not be, so even that might
>> not be safe.
>>
>> > Notthe case with, say, XML - my personal nagging example is
>> > from KML (Google map markup dialect) where IIRC a "ScreenOverlay" and a
>> > "screenoverlay" both existing with different semantics. Ugh.
>>
>> Ugh indeed. Why? Why? Why?
>>
>> > So indeed, I'd probably _want_ .upper to return a plain string and have
>> > special methods to do more targetted things as appropriate.
>> >
>>
>> Agreed.
>>
>> 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/T7FZ3FIA6INMHQIRVZ3ZZJC6UAQQCFOI/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
>
> --
> Christopher Barker, PhD (Chris)
>
> Python Language
[Python-ideas] Re: Null wildcard in de-structuring to ignore remainder and stop iterating
On Sat, Jun 18, 2022 at 5:42 PM Rob Cliffe via Python-ideas < python-ideas@python.org> wrote: > To me, the natural implementation of slicing on a non-reusable iterator > (such as a generator) would be that you are not allowed to go backwards > or even stand still: > mygen[42] > mygen[42] > ValueError: Element 42 of iterator has already been used I agree that indexing an iterator such that it could only go forward feels like a reasonable and useful feature in python, but I disagree about the ValueError. To me the above produces two values: the 43rd and 85th elements produced by mygen. Anything else is a bizarre error waiting to arise at obscure times. What if this iterator is passed to another function? Used in a loop? Now this information about what index has been used has to be carried around and checked on every access. Regards, Jeremiah ___ 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/K2CBKLZT76AS6MFYBMU3YCP4BP26P2IP/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Bare wildcard in de-structuring to ignore remainder and stop iterating (restart)
On Sun, Jun 19, 2022 at 1:01 PM Chris Angelico wrote: > On Mon, 20 Jun 2022 at 05:32, Mike Miller > wrote: > > > > My first thought was next(), which I use occasionally: > > > > It's fine for exactly two elements, where you'll never need to adjust > the code to want three, and where you know already that this is an > iterator (not some other iterable). If you had five elements to > unpack, it would be quite clunky, and even more so if you wanted to > change the precise number of elements unpacked, as you'd have to match > the number of next calls. > What if next grew a new argument? Changing the signature of a builtin is a big change, but surely not bigger than new syntax? If we could ask for the number of items returned the original example might look like >>> first, second = next(iter(items), count=2) I don’t think anyone who has started to learn python would be confused by this. And this new arg could be combined with the existing default to avoid possible exceptions. >>> spam, eggs, cheese = next(range(1), 9, count=3) >>> spam, eggs, cheese … 0, 9, 9 I guess this is starting to look like the islice solution, but now it’s magically in the builtin namespace. I don’t recall ever using islice myself, but I would believe the one argument form to be the most commonly used. ___ 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/PRSY3NYT4Z74DNETVSCH37SXDNELIZ7N/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Whitespace handling for indexing
While that formatting does look nice, this would be a huge change to the
parser just to allow a new formatting style. Right now lines are only
logically joined if they appear between a pair of () [] or {}, or if the
line ends in a \. Besides the complication of joining lines under new
circumstances, all the current options have a marker that the parser knows
about before it encounters the newline. With this new proposal the parser
will have to walk an arbitrary number of lines ahead to determine if there
are going to be new indexing operations. That won't really work at all in
the REPL or any other line-fed interpreter loop.
Currently you can add parentheses to get just about the same visual:
(foo["bar"]
["baz"]
["eggs"]
["spam"] = 1)
On Tue, May 24, 2022 at 7:44 AM Jan Costandius
wrote:
> I think that it would be beneficial for PEP 8 conformance, in the case of
> large nested dicts, if one were able to separate dict indices by a newline.
> What I mean is shown below:
>
> foo["bar"]
> ["baz"]
> ["eggs"]
> ["spam"] = 1
> ___
> 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/TKY4F4SRJEE257AXIJGSZCP3GAGU7YHA/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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/FAHKRWABUOYHHVU6R7ZFLKY4IBB6HYTM/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Syntax proposal of for..in..if in regular for loops
I have on a few occasions wanted a for..in..if statement and if it existed would have used it. However, I agree that the level of change a new statement type brings to the language is probably too high for this feature. But what if python lifted the newline requirement for blocks that contain compound statements? That is, statements that end in a ':' can be followed by other statements that end in a ':' on the same line. AFAICT there would be no ambiguity (to the parser; to humans, depends). Doing so would add the OPs requested feature, though it would be two statements on one line with one extra character. It would also essentially bring the full comprehension syntax to for loops since fors and ifs could be chained arbitrarily. # for..if for x in y: if x in c: some_op(x # nested generator-like for for line in doc: for word in line.split(): spellcheck(word) # side effect one-liner for item in an_iterable: if condition(item): side_effect(item)) Regards, Jeremiah ___ 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/LWPJKAN37ZV7G2GW33ID7PFMT7BNNOYO/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Accessing target name at runtime
On Sat, Oct 16, 2021 at 6:22 AM Erik Demaine wrote: > > It's not especially short, and it's not backward-compatible, > but at least there's a history of adding double-underscore things. > Perhaps, for backward compatibility, the feature could be disabled in any > scope (or file?) where __lhs__ is assigned, in which case it's treated > like a > variable as usual. The magic version only applies when it's used in a > read-only fashion. It's kind of like a builtin variable, but its value > changes on every line (and it's valid only in an assignment line). > This could probably be toggled via a __future__ import which would make its usage more apparent to readers of the file. But this would imply that the keyword would eventually be turned on by default; I don't think there are any examples of __future__ imports intended to be left forever as options for the programmer. I would be against any sort of magic replacement-only-when-otherwise- NameError. It seems to easy to mistakenly change it value because the namespace of locals or globals changed somewhere else. Regards, ~ Jeremiah ___ 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/AXG435QEB6T73EPAHEHGM6TYJQL2UW62/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Accessing target name at runtime
On Sat, Oct 16, 2021 at 8:46 AM Steven D'Aprano wrote: > On Sat, Oct 16, 2021 at 09:19:26AM -0400, Erik Demaine wrote: > > > To me (a mathematician), the existence of this magic in def, class, > import, > > etc. is a sign that this is indeed useful functionality. As a fan of > > first-class language features, it definitely makes me wonder whether it > > could be generalized. > > Obviously it is useful, because we have four major uses for it: imports, > classes, functions and decorators. And I can think of at least two minor > uses: the three argument form of type(), and namedtuple. > > The question is, are any additional uses worth the effort and potential > ugliness of generalising it? > > Not every generalisation is worth it. Sometimes you can overgeneralise. > > > https://www.joelonsoftware.com/2001/04/21/dont-let-architecture-astronauts-scare-you/ > > Until we have some compelling use-cases beyond the Big Four, I think > this is a case of YAGNI. > > https://www.martinfowler.com/bliki/Yagni.html > > I've been thinking about use-cases for this feature for literally > *years*, I've even got a handful of rough notes for a proto-PEP written > down. To my embarrassment, today was the first time I realised that > imports are also an example of this feature. So it is possible that > there are many great use-cases for this and I just can't see them. > You made me realize what the four built-in methods of accessing target name have in common: they are all building namespaces. Okay so maybe decorators aren't creating a new namespace, not beyond what def already does, and def isn't often thought of as a means to create a new namespace but it certainly does. So not having this access impeeds a pythonista's ability to create novel namespaces. This token alone isn't going to make new namespace types effortless, but it is maybe the last piece not already available at runtime. And yes we already have SimpleNamespace for just creating a bag of things. But a SimpleNamespace is still a class object when broken down, It's just one that does some namespace things better than object. There is actually at least one more first class use of target names: that of async def. This is different than def because it is creating a CoroutineType not simply a FunctionType. Python actually has many different types that can be created using the def keyword, but async shows that sometimes it is not even enough to use a decorator, or a metaclass with a __call__. Having access to the target would allow for new function types as well as new namespace types. Finally, sometimes the name a class instance is assigned to *is* very significant and needs to be taken into account when creating it. These are for instance the classes given here as examples from the typing module, or for a sentinel class that in only ever be used as instances. It is not always possible, or desirable, to subclass and work with class objects rather than instances just to have access to the binding name. > But I'm not sure what the best mechanism is. > > The mechanism is probably easy, if built into the compiler. When the > compiler sees something that looks like a binding operation: > > target = expression > > it knows what the target is. If the expression contains some magic > token, the compiler can substitute the target as a string for the magic > token. (There is at least one other possible solution.) > > So the implementation is probably easy. It is the design that is hard, > and the justification lacking. > Yes, this is what my toy PoC does. It replaces the node with a string while building the AST. Regards, ~Jeremiah ___ 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/PDFEPDVKHZO72M6KZR6FHXG7H7SBPRXC/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Accessing target name at runtime
On Fri, Oct 15, 2021 at 2:53 PM Chris Angelico wrote:
> On Sat, Oct 16, 2021 at 8:22 AM Jeremiah Paige wrote:
> >
> > Here is a pseudo-program showing where I would like to use this token in
> > my own code if it existed. I think besides the cases where one is forced
> to
> > always repeat the variable name as a string (namedtuple, NewType) this
> > is an easy way to express clear intent to link the variable name to
> either
> > its value or original source.
> >
> > >>> REGION = os.getenv(<<<)
> > >>> db_url = config[REGION][<<<]
> > >>>
> > >>> name = arguments.get(<<<)
> > >>>
> > >>> con = connect(db_url)
> > >>> knights = <<<
> > >>> horse = <<<
> > >>> con.execute(f"SELECT * FROM {knights} WHERE {horse}=?", (name,))
>
> Toys like this often don't sell the idea very well, because there's a
> solid criticism of every example:
>
> 1) The environment variable REGION shouldn't be assigned to a variable
> named REGION, because it's not a constant. In real-world code, I'd be
> more likely to write >> region = os.getenv('REGION') << which wouldn't
> work with this magic token.
> 2) I'd be much more likely to put the entire config block into a
> variable >> cfg = config[os.getenv("REGION")] << and then use
> cfg.db_url for all config variables, so they also wouldn't be doubling
> up the names.
> 3) Not sure what you're doing with arguments.get(), but if that's
> command line args, it's way easier to wrap everything up and make them
> into function parameters.
> 4) I've no idea why you'd be setting knights to the string literal
> "knights" outside of a toy. If it's for the purpose of customizing the
> table name in the query, wouldn't it be something like >> table =
> "knights" << ?
>
> I'm sure there are better examples than these, but these ones really
> aren't a great advertisement.
>
I'll admit I don't really have any further examples. After this idea came up
I found myself occasionally typing out code where I tried to reach for it
and wishing it was already implemented. But saying "I literally had to type
T = TypeVar("T") four times!" is not in itself a compelling example. Even
though I know I will have to type it again, and will again feel weird that
there is no better way to write this in python. I don't really write factory
functions this way myself, I just use them with what sounds like more
regularity than some.
I would absolutely use this syntax to gather some env vars, or declare
string flags, like in tix.py. My real world example that got me to circle
back
to this idea was writing a scraper that would collect as much metadata as
possible from a package. This meant walking many different static config
files that have lots of optional branches, or branches that can hold many
different kinds of data. This is the short bit that reads in a package's
long
description from pyproject.
>>> if readme := project.get("readme"):
>>> if isinstance(readme, str):
>>> self.readme = self._read_file(readme, "utf-8")
>>> elif text := readme.get("text"):
>>> if "file" in readme:
>>> raise CorruptPackage()
>>> self.readme = text
>>> else:
>>> charset = readme.get("charset", "utf-8")
>>> self.readme = self._read_file(readme["file"], charset)
A lot of lines in this example block are creating very short lived variables
based on the key name in the file read. I want the names to be kept in sync
with the config file, even though I have no fear of this specific standard
changing.
However you already said that unpacking in expression assignment is not
selling
the new syntax. And I see no one else sticking their head up to say this is
of
interest.
Regards,
~ Jeremiah
___
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/SFMN3L7AZ2GWJUQBC34DKF6ZOMKQA7DC/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Accessing target name at runtime
On Fri, Oct 15, 2021 at 3:37 PM Ricky Teachey wrote: > You say a soft keyword isn't an option and I understand why, but what > about one that is incredibly unlikely to have been used very often? I'm > thinking of just a simple double underscore: > > >>> a = __ > >>> a > 'a' > > This would be a breaking change, but surely __ is not in widespread > use...? And I think it looks a bit of alright. > > >>> Point = NamedTuple(__, "x y") > > --- > Ricky. > > "I've never met a Kentucky man who wasn't either thinking about going home > or actually going home." - Happy Chandler > > IIRC those implementing pattern matching want to use `__` as literally a non-binding name. They can't use `_` as is done in some other languages as that name is used with some regularity by python modules. Regards, ~ Jeremiah ___ 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/TVJV7AV6UT4XXS2JFSZUEA7JXWZ2KUWM/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Accessing target name at runtime
On Fri, Oct 15, 2021 at 2:32 PM Guido van Rossum wrote: > I suspect there won’t be enough support for this proposal to ever make it > happen, but at the very least could you think of a different token? The > three left arrows just look too weird (esp. in the REPL examples, where > they strongly seem to suggest a false symmetry with the ‘>>>’ prompt. How > did you decide to use this symbol? > Yes, I would consider a different token. I am not the happiest with `<<<` to start with. I wanted a symbol that evoked "this value comes from the left hand side of the assignment". Most symbols containing a `=` either already mean some sort of assignment, or look like they might become an assignment operator in the future. I went with an arrow, pointing to the target, but one that doesn't conflict with any existing arrow symbols. When this idea first surfaced on ideas it was spelled `@@` which doesn't really seem to evoke anything; maybe that's good as it can't be confused, but I was hoping for an intuitive symbol. `$` also made some sense to me as referring to the target, but felt maybe out of place in python. So perhaps `$`, `%%`, or `@@`? It doesn't feel important enough, even to me, to use a keyword, and soft keywords are out because of where it is allowed. I'm open to other suggestions. Regards, Jeremiah ___ 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/QTEELXQPG5Z4WBFGKCWKHDHUZUPYUKME/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Accessing target name at runtime
On Fri, Oct 8, 2021 at 4:27 PM Chris Angelico wrote: > On Sat, Oct 9, 2021 at 10:02 AM Jeremiah Paige wrote: > > > > On Fri, Oct 8, 2021 at 2:30 PM Chris Angelico wrote: > >> > >> On Sat, Oct 9, 2021 at 6:24 AM Jeremiah Paige > wrote: > >> > Bellow are some examples of where I believe the reflection token > would be used if adopted. > >> > > >> > > >> > >>> Point = namedtuple(<<<, 'x, y, z') > >> > >>> Point > >> > > >> > > >> > > >> > >>> UUIDType = NewType(<<<, str) > >> > >>> UUIDType > >> > __main__.UUIDType > >> > >> Not very commonly needed. The class keyword handles this just fine; > >> namedtuple does require that repetition, but I don't know of any other > >> cases where people construct types like this. > > > > > > Besides these two and the two more in the test file, the standard > > library has type, new_class, import_module, TypedDict, ParamSpec, > > and probably more, less used, factories I have missed. > > But most of those don't need to be used with constants. You don't use > the type constructor when you could just use a class statement. I'm > not sure about the others since I have literally never used them in > production; which is an indication of how much they need special > syntax to support them (namely: approximately zero). > > >> > >>> class Colors(Enum): > >> > ... Black = <<< > >> > ... GRAY = <<< > >> > ... WHITE = <<< > >> > ... > >> > >>> Colors.GRAY.value > >> > 'GRAY' > >> > >> Can do this just as easily using Enum.auto(). > > > > > > That's fair, but this works for constants in dataclasses, attrs, > generally > > any class or namespace. > > Can you provide better examples then? When you offer a new piece of > syntax, saying "well, it could be useful for other things" isn't > nearly as convincing as actual examples that will make people's lives > better. > > >> > >>> HOME = '$' + <<< > >> > >>> HOME > >> > '$HOME' > >> > >> Wow, this is so incredibly useful. I'm sure I would use this construct > >> *at least* once per decade if it existed. > > > > > > Perhaps the concatenation, showing it is just a string, was a poor > > example. In my own code I often make strings that are reused, such as > > for dict key access, variables of the same spelling. It looks like > cpython > > also does this at least a few hundred times. > > Again, need better examples if it's to be of value. Preferably, show > places where it's not just a matter of saving keystrokes (which are > cheap) - show places where it reduces errors. > > > The syntax is not only helpful to dictionary unpacking, but any > retrieval by > > string and so is general to e.g. match.group, list.index, Message.get. > > Match groups (assuming they're named - personally, I more often use > positional groups) and Message.get are definitely a plausible use-case > for something, but this syntax isn't really selling it. I've no idea > what your use-cases for list.index are. > > A generic unpacking syntax might be plausible, but it would need to > handle multiple unpackings in a single operation, and it'd achieve > something like: > > spam, ham, eggs, sausages = foo["spam"], foo["ham"], foo["eggs"], > foo["sausages"] > > Writing that in a way that doesn't involve repeating the keys OR the > thing being unpacked *would* be tempting, but the syntax you're > proposing can't handle that. > > If your use-cases are like this, I would be much more inclined to > recommend class syntax, maybe with a suitable decorator. It's a great > way to create a namespace. You can do all kinds of namespace-like > things by starting with a declarative structure and then giving that > to whatever function you like. > > 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/QADKWE5MIVB43CZTRULRNLSFTRF4FFIM/ > Code of Conduct: http://python.org/psf/codeofconduct/ Here is a pseudo-program showing where I would like to use this token in my own code if it existed. I think besid
[Python-ideas] Re: Accessing target name at runtime
On Fri, Oct 8, 2021 at 2:30 PM Chris Angelico wrote:
> On Sat, Oct 9, 2021 at 6:24 AM Jeremiah Paige wrote:
> > Bellow are some examples of where I believe the reflection token would
> be used if adopted.
> >
> >
> > >>> Point = namedtuple(<<<, 'x, y, z')
> > >>> Point
> >
> >
> >
> > >>> UUIDType = NewType(<<<, str)
> > >>> UUIDType
> > __main__.UUIDType
>
> Not very commonly needed. The class keyword handles this just fine;
> namedtuple does require that repetition, but I don't know of any other
> cases where people construct types like this.
>
Besides these two and the two more in the test file, the standard
library has type, new_class, import_module, TypedDict, ParamSpec,
and probably more, less used, factories I have missed.
> > >>> class Colors(Enum):
> > ... Black = <<<
> > ... GRAY = <<<
> > ... WHITE = <<<
> > ...
> > >>> Colors.GRAY.value
> > 'GRAY'
>
> Can do this just as easily using Enum.auto().
>
That's fair, but this works for constants in dataclasses, attrs, generally
any class or namespace.
> > >>> HOME = '$' + <<<
> > >>> HOME
> > '$HOME'
>
> Wow, this is so incredibly useful. I'm sure I would use this construct
> *at least* once per decade if it existed.
>
Perhaps the concatenation, showing it is just a string, was a poor
example. In my own code I often make strings that are reused, such as
for dict key access, variables of the same spelling. It looks like cpython
also does this at least a few hundred times.
>
> > >>> if error := response.get(<<<):
> > ... if errorcode := error.get(<<<):
> > ... print(f"Can't continue, got {errorcode=}")
> > ...
> > Can't continue, got errorcode=13
>
> Ugh. I'm sure there would be better ways to advocate unpacking but
> this really isn't selling it.
>
> > To get a feel for using this new token I have created a fork of the 3.11
> alpha that implements a *very* incomplete version of this new grammar, just
> enough to actually produce all of the examples above. It also passes a
> small new test suite with further examples
> https://github.com/ucodery/cpython/blob/reflection/Lib/test/test_reflection.py
> .
> >
>
> General summary based on all of the examples in that file: Use the
> class statement more. There is absolutely no reason, for instance, to
> use make_dataclass in this way - just use the class statement instead.
> There *may* be some value in the use of TypeVar like this (not sure
> though), in which case there'd be two mildly tempting use-cases,
> neither of which is hugely common (TypeVar and namedtuple). For the
> rest, a big ol' YAGNI on a syntax that badly impairs readability.
>
> And while I would somewhat like to see a dictionary unpacking syntax,
> this really isn't selling the concept well.
>
The syntax is not only helpful to dictionary unpacking, but any retrieval by
string and so is general to e.g. match.group, list.index, Message.get.
Regards
~ Jeremiah
___
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/WOCRCFG4465CFVCQ5DDYBZ34IQO553HL/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Accessing target name at runtime
Hello Python community,
Earlier this year I put forward a proposal for decorators on variables
which I felt was well received in concept, but fell flat on the syntax. One
of the responses to that thread was rather than abusing the decorator, to
use a new symbol to get the target of an assignment statement as a string
on the right hand side. I would call this compile-time reflection of
assignment targets, or simply reflection. Although initially continuing on
with my original syntax, the idea of using such a token in my own code came
up on more than one occasion this year and I wanted to see what it might
really look like.
>From that, this proposal is to add a new token to Python, currently spelled
<<<, which, at compile time, is replaced with the string representation of
the nearest assignment target, either assignment statement or assignment
expression. It does not bind with either keyword arguments or default
parameters. Neither does it work in any kind of non-assignment binding.
When encountered anywhere other than the right hand side of some
assignment, it is an unconditional SyntaxError.
Having access to the target at runtime is most often useful in meta
programming and the standard library has several factory functions that
require the user to repeat the variable name in the function call to get
expected behavior. Bellow are some examples of where I believe the
reflection token would be used if adopted.
>>> Point = namedtuple(<<<, 'x, y, z')
>>> Point
>>> UUIDType = NewType(<<<, str)
>>> UUIDType
__main__.UUIDType
>>> class Colors(Enum):
... Black = <<<
... GRAY = <<<
... WHITE = <<<
...
>>> Colors.GRAY.value
'GRAY'
>>> HOME = '$' + <<<
>>> HOME
'$HOME'
>>> if error := response.get(<<<):
... if errorcode := error.get(<<<):
... print(f"Can't continue, got {errorcode=}")
...
Can't continue, got errorcode=13
To get a feel for using this new token I have created a fork of the 3.11
alpha that implements a *very* incomplete version of this new grammar, just
enough to actually produce all of the examples above. It also passes a
small new test suite with further examples
https://github.com/ucodery/cpython/blob/reflection/Lib/test/test_reflection.py
.
___
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/TXKXQUFBCSACRDOAEAZXSMMCEYX265FV/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: String method to check for a float
If the end goal is to just get either a float or an int from a string, and
you want to only accept floats the way Python spells them, what about using
ast.literal_eval?
>>> type(ast.literal_eval('1'))
>>> type(ast.literal_eval('1.0'))
>>> type(ast.literal_eval('01_105e-3'))
On Sun, Oct 3, 2021 at 1:31 AM Debashish Palit wrote:
> There are plenty of use cases if you pause to think. The other objections
> are trivial. Even the simplest usage with the input() function is enough to
> warrant its inclusion, considering that there are other useless string
> methods.
>
> As I have had no support for the past few days, I quit the discussion.
> ___
> 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/VJV3A4GDV2MLUUEBSFOTWJBZ2F6LDXF3/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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/6WBGEYEXFSVXWPUDJ7EITLWICIU4KS74/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: os.workdir() context manager
On Wed, Sep 15, 2021 at 4:20 AM Steven D'Aprano wrote: > On Wed, Sep 15, 2021 at 08:53:21PM +1000, Chris Angelico wrote: > > > Sometimes there is no valid path to something, > > I don't understand what you mean by that. If there is no valid path to > something, where exactly are you cd'ing to, and how does it help you > with the thing that has no valid path to it? > No one has mentioned the other case where cd'ing somewhere makes paths suddenly valid, and that is for long path names. Once you pass PATH_MAX length your only options are to cd as deep as possible and continue relatively, or to pass dir fds. The second is perhaps the better option, but harder to implement as you have to handle extra fds and remember to clean them up and I at least never remember how to thread fds through python code without going and looking it up. This also brings up the issue of how to restore the prior working directory. Just remembering its path and calling a new chdir will fail, both in the long path case and in the case that the old dir was deleted since last visit. We could hold an open fd before leaving the old cwd, and that should allow us to return in both cases. However I don't know how others feel about holding on to dir fds, especially essentially hidden ones; it sounds ripe for FS deadlock. Regards, ~Jeremiah ___ 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/L37QIXGPPBSQJFOHI5O3QZCKDEHKDVTJ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: synatx sugar for quickly run shell command and return stdout of shell command as string result
On Thu, Aug 26, 2021 at 5:53 AM Evan Greenup via Python-ideas <
python-ideas@python.org> wrote:
> Currently, when what to execute external command, either os.system() or
> subprocess functions should be invoked.
>
> However, it is not so convenient, it would be nice to use "``" symbol to
> brace the shell command inside.
>
> like:
>
> stdout_result_str = `cat file.txt | sort | grep hello`
>
> Its is enhanced feature which combine both subprocess and os.system
>
> Because, subprocess can return output of file, but does not support pipe
> in command.
>
subprocess.run('cat file.txt | sort |grep hello', shell=True
capture_output=True, check=True, text=True, encoding="utf8").stdout
you can use any piping or redirection you like.
However, I do like the idea of run() having the ability to easily chain
commands without the need to pull in the shell.
Is this too magical? result = run('cat file.txt') | run('sort) | run('grep
hello', capture_output=True, text=True).stdout
I'm sure there are other approaches. We don't often have to worry about
file handles in python, and it would be nice
to remove this worry from subprocess pipes even more than it already is.
___
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/TXUDW3XOKASHSYD4JJYOFXCBFRXPGS5H/
Code of Conduct: http://python.org/psf/codeofconduct/
