[Python-ideas] Re: Extending LiteralString or Literal with structural validation

[Ricky Teachey]

On Tue, Dec 20, 2022 at 11:17 PM Stephen J. Turnbull <
stephenjturnb...@gmail.com> wrote:

> Ricky Teachey writes:
>
>  > This isn't to say it should definitely be added to the language, that's
> a
>  > tough hurdle. But boy would I have used it.
>
> IIUC, Mathew's idea doesn't need to be added to *the* language (the
> one defined by the Language Reference).  It needs to be added to the
> languages used by type checkers.
>
> So if you want this and know a type checker author, send them pizza! :-)
>
> Steve
>

Unfortunately subclassing LiteralString is a TypeError at this time. Otoh
something like this doesn't necessarily have to be a LiteralString child
class, but it does mean someone who is a little more knowledgeable than I
would have to write such a CustomString parent class, or custom_str()
factory.

Anyway I guess probably this is a discussion for the typing mailing list.
Maybe the OP should consider taking it there?

---
Ricky.

"I've never met a Kentucky man who wasn't either thinking about going home
or actually going home." - Happy Chandler
___
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/FMVFUFBA2DWZRRYMN6SNIJSSENDWXLL7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Extending LiteralString or Literal with structural validation

[Ricky Teachey]

Chiming in to say this is a really neat idea and I would definitely have
used this in the past, especially when doing programming where it would
have been much more useful to know about errors at coding time and not at
runtime.

This isn't to say it should definitely be added to the language, that's a
tough hurdle. But boy would I have used it.

On Tue, Dec 20, 2022, 6:33 AM Mathew Elman  wrote:

> This is somewhat inspired by the "Tagged strings in python" thread, but
> from a different approach.
> Specifically, rather than messing with runtime python, using static type
> analysis to help the usability of specific kinds of string literals.
>
> It would be useful to take advantage of the `LiteralString` or `Literal`
> type hints to add structural validation to literals.
>
> For *example*, if these could be subclassed to add a validation method:
> class MyLiteral(LiteralString):
> def __validate__(self):
> ...
>
> or extended to allow something like regex in there generic type parameter:
> Literal[r"\w+"]
> LiteralString[r"\w+"]
>
> then specific kinds of literal string can be "enforced" by static type
> checkers.
> Then IDEs could at the very least highlight that a string literal is not
> valid.
>
> I stress these are just examples, the goal is to have a way to tell a
> static type checker what the structure of a string literal has to be.
> ___
> 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/37OZHV2KNILDMO4WVOHOZZADVYPLQWE3/
> 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/OBLT2XLKTAC6RSC5K6T5Y3IFRGQBQ2KK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Native support for units [was: custom literals]

[Ricky Teachey]

On Tue, Apr 12, 2022 at 11:27 AM Christopher Barker 
wrote:

>  > > I guess you could call the associative law of multiplication "dumb
>>  > > luck", but most mathematicians will consider that hate speech.
>>  >
>>  > My apologies for not understanding your example.  The counter
>>  > example I had in my head, and should have written down,
>>  > was something like:
>>  >
>>  >15mpg * 7l == how many miles?
>>
>
> Using pint:
>
> In [76]: U = pint.UnitRegistry()
>
> In [77]: (15 * U.miles / U.gallons * 7 * U.liter).to('miles')
> Out[77]: 27.7380654976056 
>
> A bit verbose, perhaps, but to me clear, and the operator precedence rules
> seem to "just work".
>
> And it you want it a tad less verbose, you can give some of those units
> names:
>
> In [78]: mpg = U.miles / U.gallons
> In [79]: l = U.liter
>
> In [80]: (15 * mpg * 7 * l).to('miles')
> Out[80]: 27.7380654976056 
>
> My question for the folks that want units built in to Python is "what's so
> hard about that?
>
> Ricky wrote:
>
> "Python is so painful to use for units I've actually avoided it,"
>
> Really? have you tried pint? or anything else? what is so painful about
> this?
>
> -CHB
>
> --
> Christopher Barker, PhD (Chris)
>

I will try to finish my email about this I started writing a week ago!

---
Ricky.

"I've never met a Kentucky man who wasn't either thinking about going home
or actually going home." - Happy Chandler
___
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/SO456QXMDO6TSCIFYVOX4AHGECFLCMAB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Native support for units [was: custom literals]

[Ricky Teachey]

On Fri, Apr 8, 2022, 2:40 AM Stephen J. Turnbull 
wrote:

> Brian McCall writes:
>  Steven d'Aprano writes:
>
>  > > you have shown nothing to justify why unit support must be built
>  > > into the language itself.
>  >
>  > I did what I could, but I'm not going to try and justify any more.
>
> That makes me sad, because everybody in the thread acknowledges that
> improving the Python distribution's support for units is a good idea,
> but nobody is as enthusiastic about getting it done as you.
>
> Chris Barker's comments about multiple attractive library
> implementations are well-taken, I think, but I also think that with
> more focus on getting a satisfactory module into the stdlib, it would
> be quite possible to pick one that doesn't rely on non-stdlib types
> (so I guess astropy.units would be out).
>
> That doesn't directly get you the literal syntax for units you focus
> on, but if units are easier to use, more applications will use them,
> and perhaps build up momentum for a syntax change.  And the syntax
> change is useless without the library.
>

I'll try to provide examples of my struggles with units in python but I'm
not an accomplished coder at all and don't have much to look at in the way
of examples. I sometimes go weeks without writing any code at all, followed
by days of nothing but writing code.

Python is so painful to use for units I've actually avoided it, so there
won't be many examples I can give anyway. Hence my silence in this thread
the past few days.

I just get really excited at the idea of it being native to the language
and am dreaming of being able to use it more often for my every day
calculations. Right now I just don't feel confident I can.
___
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/LSQQKL72J5AWCCZFHVY2M4RJFU7Y6OGH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Native support for units [was: custom literals]

[Ricky Teachey]

On Tue, Apr 5, 2022 at 7:43 AM Steven D'Aprano  wrote:

> On Mon, Apr 04, 2022 at 01:53:49PM +1000, Chris Angelico wrote:
>
> > And that's exactly why I think that the *concept* of units could be
> > added to the language, with some syntax and low-level semantics, but
> > the actual units themselves belong in libraries.
>
> +1 on that.
>
> I'm not even sure about the need for syntax beyond what we already have.
> Yes, it would be nice to write:
>
> speed = 15 ft 3 in / 3 sec
>
> but is it really so painful to use existing syntax?
>
> speed = (15*ft + 3*in) / (3*sec)
>
> I don't think so.
>
>
> --
> Steve
>

The motivation is much more than just being able to not have the * symbol
(though all things being equal it would be nice).

I think I've mostly disagreed with Brian McCall on just about every DETAIL
he has expressed regarding what "language level unit system support" ought
to look like, but he had it right in his first post that spurred this
discussion. I'll quote bits of it:

On Sun, Apr 3, 2022 at 2:56 PM Brian McCall 
wrote:

> ...I have spent a fair amount of my own time, and I have seen so many
> others' time wasted because command line or input fields do not include
> units, or the inputs field units are accidentally handled with different
> units, or units are not used at all.
>
> I get the sentiment that Python, or programming languages in general, are
> not meant to deal with units. From the perspective of a computer scientist,
> I can understand why this would be seen as a level of abstraction too high
> for programming languages and core libraries to aspire to. But from the
> perspective of a scientist or engineer, units are a CORE part of language.
> Anyone who has taken science or engineering classes in college knows what
> happens when you turn in homework with missing units in your answers - zero
> credit. Anyone who has worked out complicated calculations by hand, or with
> the help of packages like "units" knows the sinking feeling and the red
> flags raised when your answer comes out in the wrong units.
>
> There has also been a shift in the expectations of scientists and
> engineers regarding their programming capabilities. A generation ago, a
> good many of them would not be expected to use their computers for anything
> more than writing documents, crunching numbers in a spreadsheet, or using a
> fully integrated task-specific application for which their employer paid
> dearly. These assumptions were codified in workflows and job descriptions.
> Today, if your workflow, especially in R&D, has a gap that Microsoft Office
> or task-specific software doesn't solve for you, then you are pretty much
> expected to write your own code. Job postings for engineering roles (other
> than software engineering) regularly include programming in their required
> skills. Software design, on the other hand, is rarely a required or hired
> skill. And even though these scientists and engineers are required to know
> how to program, they are almost never *paid* to write code. Spending any
> more time than needed writing code, even if it is to fill a critical gap in
> a workflow, is seen as a negative. So software design best practices are
> non-existent. All of this leads to very poor practices around and improper
> handling of an absolutely essential part of scientific and engineering
> language - units.
>
> ...The lack of native language support for SI units is a problem for an
> entire segment of programmers. Programming languages took a big step
> forward in deciding that EVERYTHING is a pointer/reference, and EVERYTHING
> is an object. They need to take another step forward to say that EVERY
> number has a unit, including "unitless". Not having this language feature
> is becoming (or already is) a problem. The question is, is it Python's
> problem?


And I said:

The old engineering disciplines- mine (civil engineering), structural,
> electrical, etc- are the next frontier in the "software eats the world"
> revolution, and they desperately need a language with native units
> support
>
>  Python SHOULD be that language we do this with. It is awesome in every
> other way. But if it isn't DEAD SIMPLE to use units in python, it won't
> happen.
>

Steven: I am telling you that there is a HUGE NEED and DESIRE for what we
are talking about above. the need to automate design processes in the "i
need you to get me a set of calculations and drawings for this complicated
project to me, TODAY, mr engineer?" electrical, structural, chemical,
industrial/manufacturing, mechanical, and general civil (environmental,
water/wastewater, geotechnical, chemical, transportation) fields is
monstrous. it said above it is "the next frontier". but it won't be unless
these men and women get the tools they need. someone is going to fill the
need.

units are at THE CORE of that need.

i think python should be the language we reach for. i have made python work
for me as a civil engineer and been extremely successfu

[Python-ideas] Re: Native support for units [was: custom literals]

[Ricky Teachey]

On Mon, Apr 4, 2022 at 2:24 PM Steven D'Aprano  wrote:

> On Sun, Apr 03, 2022 at 10:42:16PM -0400, Ricky Teachey wrote:
>
> > I was cheerleading this effort earlier and I still think it would be a
> > massive contribution to needs of the engineering world to solve this
> > problem at the language level. But boy howdy is it a tough but of a
> problem
> > to crack.
>
> More than 35 years of prior art says hello.
>
> My HP-28C calculator supported unit conversion in the mid 1980s, and a
> few years later HP were offering calculators that supported arithmetic
> on units.
>
> If you want to see some prior art, check out the chapters on Units here:
>
>
> https://web.archive.org/web/20150608024051/http://www.hp41.net/forum/fileshp41net/hp28sref.pdf
>
> http://h10032.www1.hp.com/ctg/Manual/c00442266.pdf
>
> If you are on a Linux or Unix system, you can check out the "units"
> program:
>
> [steve@ando ~]$ units "3 ounces * 200 furlongs per fortnight" "kg m/s"
> * 0.0028288774
> / 353.49711
>
>
> Then there is also Frink:
>
> https://frinklang.org/
>
>
> --
> Steve


These are cool finds. There is also Mathcad, which beautifully solved the
units problem well over 2 (3?) decades ago. Of course a Mathcad seat ain't
cheap. And there's Maple, and matlab.

All of these probably have things to teach us. Here is a screenshot of the
Mathcad units system definition interface; it doesn't solve all the
problems, but it solves many.

[image: image.png]

---
Ricky.

"I've never met a Kentucky man who wasn't either thinking about going home
or actually going home." - Happy Chandler
___
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/ILSL7E26TK7GSKBQHII5ZLEBVQCIT7IN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Native support for units [was: custom literals]

[Ricky Teachey]

On Mon, Apr 4, 2022 at 11:55 AM Ken Kundert  wrote:

> I think there is one more point worth making here.  There is a suggestion
> that
> dimensional analysis can underpin a units system.  Actually, the idea that
> all
> units can be broken down into a small set of fundamental units is very
> limiting
> and results in many vexing issues.
>
> For example, consider currencies.  There are currently hundreds of national
> currencies and thousands of cryptocurrencies.  They all have the same basic
> fundamental unit of “value”, but value is only loosely defined.
> Furthermore,
> there is no fixed ratio between the currency and its value.  It varies over
> time, over location, and from person to person.
>
> Consider units of a particular commodity.  The example of a ream of paper
> was
> recently mentioned. A ream is 500 sheets of paper.  However two reams may
> not be
> comparable.  They may refer to a different size of paper or a different
> quality
> of paper.  So all prices for reams of paper would have the same fundamental
> units of “value per each”, but both “value” and “each” are not necessarily
> comparable.  In effect, the fundamental unit system is not complete.  You
> also
> need to include information about what you are measuring.  For example,
> “each”
> could represent a single item of anything.  The unit is not complete until
> you
> include a description of what that anything is, and in effect, there is an
> unlimited number of things it could be.
>
> Now consider the issue of “unitless units”.  In electrical circuit we
> often talk
> about gain, which it the ratio between the signal level at the output of
> a circuit relative to the signal level at the input.  But you need to be
> specific about how you measure signal level.  Typically, it would be a
> voltage,
> current, or power level.  Consider a circuit where both the input and
> output are
> measured in volts.  Then the gain would have units of "V/V", which is
> unitless
> in dimensional analysis.  But units of "V/V" (voltage gain) is much
> different
> from units of "A/A" (current gain) or "W/W" (power gain), even though they
> have
> the same dimensions.  Mixing them up results in errors and confusion.  An
> additional complication is that sometimes logarithmic units are used.  For
> example, decibels in voltage, or dBV, is 20*log(Vout/Vin).  Again,
> a dimensionless quantity, but nonetheless "dBV" much different from "V/V".
>
> The same issue occurs with the arguments to trigonometric functions like
> sin(),
> cos() and tan().  Generally, we assume the arguments are given in radians,
> which
> is a dimensionless number.  But it could also be given in degrees, another
> dimensionless number.  Radians and degrees are indistinguishable from the
> perspective on dimensional analysis, but mixing them up results in errors.


Just lending support to all of these comments. These are universal problems
and far far from specific to electrical engineering. In civil we talk about
strains and moments; strains are unitless, but they still carry a unit
(e.g., in/in) and those units are important. We also talk about moments,
which are the same dimensions as for energy (FORCE X LENGTH) but a wholly
different thing with different unit expression (e.g., kip X ft). And there
is also torque, which is the same units as a moment, but a different
concept and you probably shouldn't be adding them together even though they
are exactly the same units (someone might want to argue with me about that,
I'm unsure).

There is also the 2nd moment of area per length, which is the same
dimensions as volume but we express it in different units than volume
(in4/in), and there is section modulus per length, which is the same
dimensions as area but different units (in3/in), and area per length, which
is the same as length, but different units (in2/in or in2/ft). There is
also the concept of loads: pressure loads (lbs/sq ft or psi), linear loads
(lbs/ft, kips/in, etc), and these probably come out to have the same
dimensions are other concepts in other disciplines that should not to be
added to them.

Since the concept of what a unit means is very very complex, what Chris A
is saying about punting these responsibilities out to others is very
powerful idea. I'm uncertain whether the idea of just calling functions as
the consequence of applying unit tag to a number is the right solution (but
I'm not against it).

I wonder if having a totally separated namespace for the "unit slot" makes
some kind of sense. Maybe you say something like:

from pint.SI import as units meter as m, kilogram as kg
from pint.US_Customary import as units feet as ft, pounds_force as lbf

<>

...and with the above "as units" imports you can say:

m = "mosquito"
lbf = "low battery freakout"
kg = "kill goliath"
ft = "foolish tolkien"
x = 2m
y = 5kg
a = 4.0ft
b = 4.1lbf

...etc. etc., and you have a unit namespace separate from the regular
namespace. The m and lbf and ft and kg in these spaces never conflict

[Python-ideas] Re: Native support for units [was: custom literals]

[Ricky Teachey]

On Sun, Apr 3, 2022, 11:03 PM Chris Angelico  wrote:

> > I'm unsure simple tags are enough. What should the behavior of this be?

>
> > height = 5ft + 4.5in
>
> My view on this is that it should basically be defined as:
>
> height = ft(5) + in(4.5)
>
> where you register your constructor functions (possibly types,
> possibly factory functions) using a hook in the sys module.
>

This is really similar to what pint does already (except it uses the
multiplication syntax if course).

What does that idea bring other than being able to say:

5.0m

(m registered in a previously run module)

 instead of:

5.0*m

(m an object imported in a previously run module)

?

> Surely we ought to be able to add these values. But what should the
> resulting tag be? Should we be able to write it like this?
> >
> > height = 5ft 4.5in
>
> That, I would say, no. There are a lot of human-readable notations
> that aren't supported by programming languages, such as algebraic
> "abuttal means multiplication" and such. It's not that hard to say
> "5ft + 4.5in", just like you'd say "3 + 4j" for a complex number.
>

Makes sense to me.

(Also, I don't really see a lot of point in making feet-and-inches
> minorly less complicated, given that people should be trying to use
> metric anyway.)
>

They're almost all I use professionally. I graduated college in 2010 and
have almost never used centimeters or millimeters since then. "Shoulds"
aside, feet and inches are not going away and any unit system needs to make
them first class and easy to use or it will be extremely painful for large
chunks of progressional engineers.

But 5ft+4in is fine.

> I was cheerleading this effort earlier and I still think it would be a
> massive contribution to needs of the engineering world to solve this
> problem at the language level. But boy howdy is it a tough but of a problem
> to crack.
> >
>
> This is something where (again, my view only, others may disagree) the
> language itself need not actually make a decision. Ideally, the
> standard library should have something usable, but it should be such
> that you could choose to do something else. The standard library could
> even have more than one unit system in it - for instance, you could
> have a metric-focused system that converts "5ft" into "1.524m", or you
> could have a unit-retaining system that keeps everything in the unit
> specified until such time as conversions are needed, etc.
>

Yup, being able to choose to retain units or convert them to preferred
units is important.

One very important feature for the standard library would be a generic
> "Quantity" type, which could save a lot of hassle. You could create a
> "length" quantity and register a number of units, and define that any
> length can be added to any other length, a length can be multiplied by
> a scalar, etc, etc, etc. Then a bit of generic handling could also
> recognize that when you multiply or divide two quantities, you get
> something in a combined unit (whether that's "length*length" meaning
> area, or "length/time" meaning velocity), and libraries could slot in
> whatever units make the most sense. Maybe you're working with
> astronomical distances, and the meter just causes too many
> floating-point roundoff errors, so you define your base unit to be the
> parsec, and everything else derives from that. Or maybe you're working
> with video game analysis and the most important quantity is "items per
> minute" (eg 780 iron ore per minute), so you define each type of item
> as its own quantity, and redefine time with a basis of minutes instead
> of seconds. Having the tools to do that is probably more important
> than defining it all at the language level.
>

I like and think I understand most of what you're saying here. I think much
of this has been thought through and solved by the pint library, and some
others. Having a "slot" to natively associate a unit tag with numerical
values, and syntax support with defined semantics, could be a big win.
Leaving the "now let's make decisions about behavior" part to 3rd parties
makes sense to me.

But what superpower does bringing the notion of tagging things into the
native language bring for us if all the tag does is call a function that
returns a thing?

It almost just sounds like a postfix function call syntax to me.

>
___
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/CMIA6EN5QCEINLVNN2V2Y2K6FUQKBM3P/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Native support for units [was: custom literals]

[Ricky Teachey]

On Sun, Apr 3, 2022, 6:27 PM Chris Angelico  wrote:

On Mon, 4 Apr 2022 at 07:45, Ethan Furman  wrote:
> Mechanically, are `lbs`, `km`, `hr`, etc., something that is imported, or
are they tags attached to the numbers?  If
> attached to the numbers, memory size would increase and performance might
decrease -- but, how often do we have a number
> that is truly without a unit?
>
> How old are you?  35 years
> How much do you weigh?  300 kg
> What temperature do you cook bread at?  350 F
>

Very frequently - it'd be called an index. (What sort of numbers
should enumerate() return, for instance? Clearly that, whatever it is,
is an index.) But if every int and float has a tag attached to it,
it's not that big a deal to have either a default tag, or leave the
field NULL or None, to define it to be a unitless value or index.

ChrisA


How much memory would have to be added to every number? Could it be
dynamically sized so it doesn't have a large impact on all the code out
there with no units? But also grow to be big enough to capture the vast
constellation of units and unit combinations out there?

I'm unsure simple tags are enough. What should the behavior of this be?

height = 5ft + 4.5in

Surely we ought to be able to add these values. But what should the
resulting tag be? Should we be able to write it like this?

height = 5ft 4.5in

I was cheerleading this effort earlier and I still think it would be a
massive contribution to needs of the engineering world to solve this
problem at the language level. But boy howdy is it a tough but of a problem
to crack.
___
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/YJ5ZPNZ32DYKSGKMRWOQKZTX3Z6EJGXJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Custom literals, a la C++

[Ricky Teachey]

HEAR HEAR!

BUT-  SI units isn't enough. Engineers in the US and Canada (I have many
colleagues in Canada and when I ask they always say: we pretend to use SI
but we don't) have all kinds of units.

Give us native, customizable units, or give us death! Who's with me??!!

...


I'm kidding to a degree but I did feel a swell of excitement as I read this
response. :)

The libraries out there- pint is probably the biggest one- have filled
those gap as much as they can, but there are so many shortfalls...

The old engineering disciplines- mine (civil engineering), structural,
electrical, etc- are the next frontier in the "software eats the world"
revolution, and they desperately need a language with native units support.
I was just on an interview call yesterday for a senior engineer role at a
large multinational earth works engineering firm and we spent 15 minutes
talking about software and what we see coming down the road when it comes
to the need for our discipline to grow in its software creation
capabilities.

 Python SHOULD be that language we do this with. It is awesome in every
other way. But if it isn't DEAD SIMPLE to use units in python, it won't
happen.

I don't know what the solution is. I'm looking to you software engineers,
you true geniuses and giants of your fields, to figure that out for me. But
once you hand it to me I promise I will evangelize it to the ends of the
Earth.

On Sun, Apr 3, 2022, 2:56 PM Brian McCall 
wrote:

> *SOAP BOX WARNING*
>
> It's not often that I would say that C++ is easier to read or more WYSIWYG
> than Python, but in this case, C++ is clearly well ahead of Python. I have
> spent a fair amount of my own time, and I have seen so many others' time
> wasted because command line or input fields do not include units, or the
> inputs field units are accidentally handled with different units, or units
> are not used at all.
>
> I get the sentiment that Python, or programming languages in general, are
> not meant to deal with units. From the perspective of a computer scientist,
> I can understand why this would be seen as a level of abstraction too high
> for programming languages and core libraries to aspire to. But from the
> perspective of a scientist or engineer, units are a CORE part of language.
> Anyone who has taken science or engineering classes in college knows what
> happens when you turn in homework with missing units in your answers - zero
> credit. Anyone who has worked out complicated calculations by hand, or with
> the help of packages like "units" knows the sinking feeling and the red
> flags raised when your answer comes out in the wrong units.
>
> There has also been a shift in the expectations of scientists and
> engineers regarding their programming capabilities. A generation ago, a
> good many of them would not be expected to use their computers for anything
> more than writing documents, crunching numbers in a spreadsheet, or using a
> fully integrated task-specific application for which their employer paid
> dearly. These assumptions were codified in workflows and job descriptions.
> Today, if your workflow, especially in R&D, has a gap that Microsoft Office
> or task-specific software doesn't solve for you, then you are pretty much
> expected to write your own code. Job postings for engineering roles (other
> than software engineering) regularly include programming in their required
> skills. Software design, on the other hand, is rarely a required or hired
> skill. And even though these scientists and engineers are required to know
> how to program, they are almost never *paid* to write code. Spending any
> more time than needed writing code, ev
>  en if it is to fill a critical gap in a workflow, is seen as a negative.
> So software design best practices are non-existent. All of this leads to
> very poor practices around and improper handling of an absolutely essential
> part of scientific and engineering language - units.
>
> If you had asked me twenty years ago if I thought units should be a native
> part of any programming language, I would have said absolutely - because in
> my youthful ignorance I had no idea what it would take to make such a thing
> work. Five years later, I would have said "not worth it". Now I'm back
> where I started. The lack of native language support for SI units is a
> problem for an entire segment of programmers. Programming languages took a
> big step forward in deciding that EVERYTHING is a pointer/reference, and
> EVERYTHING is an object. They need to take another step forward to say that
> EVERY number has a unit, including "unitless". Not having this language
> feature is becoming (or already is) a problem. The question is, is it
> Python's problem?
> ___
> 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:

[Python-ideas] Re: s?scanf [was: A string function idea]

[Ricky Teachey]

parse is a great library! i've used it a lot.

---
Ricky.

"I've never met a Kentucky man who wasn't either thinking about going home
or actually going home." - Happy Chandler


On Wed, Mar 30, 2022 at 1:08 PM Paul Moore  wrote:

> On Wed, 30 Mar 2022 at 17:58, Christopher Barker 
> wrote:
> >
> > On Wed, Mar 30, 2022 at 1:50 AM Stéfane Fermigier 
> wrote:
> >>
> >> FYI, there is a “parse” library on PyPI:
> https://pypi.org/project/parse/
> >>
> >> Parse strings using a specification based on the Python format() syntax.
> >>
> >> parse() is the opposite of format()
> >>
> >> (I haven’t used it myself,
> >
> >
> > Me neither, but I do like this idea better than scanf style. And there’s
> an implementation ready to try out.
>
> +1 from me as well.
>
> Paul
> ___
> 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/3GRJX3N7536QK2WUF6VT7J2273VCZ5QI/
> 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/VSST3URVSJB6QPNUUQQ372SUBXOEM4Y5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Anonymous namedtuples, revisited

[Ricky Teachey]

On Tue, Mar 29, 2022 at 12:49 PM Ethan Furman  wrote:

> On 3/29/22 09:14, Christopher Barker wrote:
>
>  > [...] I tried to use __slots__ in TupleWithNames, but apparently you
> can't use __slots__ in a
>  > tuple subclass ('cause tuple's already using it ??) -- but that could
> be done in a builtin.
>  > then it wouldn't need a __dict__
>
> The `__dict__` is needed to store the field names -- did you add
> `__dict__` to the `__slots__`?  (Of course, if you've
> added `__dict__` then you lose the limited size of `__slots__`.)
>
> --
> ~Ethan~
>

Maybe I'm being an ignoramus but: how would it be possible to even use
slots? Slots are descriptors living in the class namespace. You don't know
ahead of time what the member names are, so you can't use slots, right?
Unless you modify the TupleWithNames class on the fly, adding slot names as
they are needed. But then you need some kind of machinery for each instance
to know which slots are valid for that instance, and to block access to
slots that aren't part of that instance.

Again, I might just be a doof.


---
Ricky.

"I've never met a Kentucky man who wasn't either thinking about going home
or actually going home." - Happy Chandler
___
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/GPDPVTWALPF63QBD4BPSAXA2VTQOTIIJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Anonymous namedtuples, revisited

[Ricky Teachey]

I think I'd often reach for an optimized version of something like this
over SimpleNamespace or even a Dataclass if it existed.

On Tue, Mar 29, 2022, 2:04 AM Christopher Barker 
wrote:

> Finally got around to fleshing out my idea here.
>
> My thought was to make an anonymous names tuple not as a new anonymous
> class, but simply as an instance with specific field names. So all of these
> would the the same class, but they would also be lightweight, and all
> subclasses of tuple -- from a typing perspective, it's just be a tuple -
> and could be used anywhere a tuple could.
>
> Here's a quick prototype I came up with:
>
> class TupleWithNames(tuple):
> def __new__(cls, **fields):
> self = tuple.__new__(cls, fields.values())
> for name, val in fields.items():
> self.__dict__[name] = val
> return self
>
> def __setattr__(self, attr, val):
> raise AttributeError("Can't set attributes on TupleWithNames")
>
> def __repr__(self):
> return f"TupleWithNames({', '.join(f'{k}={v}' for k, v in
> self.__dict__.items())})"
> In [172]: point = TupleWithNames(x=5, y=10)
>
> In [173]: point
> Out[173]: TupleWithNames(x=5, y=10)
>
> In [174]: point.x
> Out[174]: 5
>
> In [175]: point.y
> Out[175]: 10
>
> In [176]: point.x = 2
> ---
> AttributeErrorTraceback (most recent call last)
>  in 
> > 1 point.x = 2
>
> ~/PythonStuff/tuplewithnames/tuplewithnames.py in __setattr__(self, attr,
> val)
>  11
>  12 def __setattr__(self, attr, val):
> ---> 13 raise AttributeError("Can't set attributes on
> TupleWithNames")
>  14
>  15 def __repr__(self):
>
> AttributeError: Can't set attributes on TupleWithNames
>
> In [177]: point.z = 3
> ---
> AttributeErrorTraceback (most recent call last)
>  in 
> > 1 point.z = 3
>
> ~/PythonStuff/tuplewithnames/tuplewithnames.py in __setattr__(self, attr,
> val)
>  11
>  12 def __setattr__(self, attr, val):
> ---> 13 raise AttributeError("Can't set attributes on
> TupleWithNames")
>  14
>  15 def __repr__(self):
>
> AttributeError: Can't set attributes on TupleWithNames
>
> In [178]: point[0]
> Out[178]: 5
>
> In [179]: point[1]
> Out[179]: 10
>
> In [180]: point[1] = 3
> ---
> TypeError Traceback (most recent call last)
>  in 
> > 1 point[1] = 3
>
> TypeError: 'TupleWithNames' object does not support item assignment
>
> So it's a (subclass of) tuple -- you can access the entries by name, you
> can't change them.
>
> It's truly immutable, 'cause the __dict __ is there to mess with, but that
> (I think) could be fixed if it were implemented in C.
>
> This really simple version hashes as the tuple -- so it's the same as a
> tuple with the same values, or a TupleWithNames with the same values, and
> any arbitrary names.
>
> Which I think is OK -- the idea here is that it IS just like a tuple
> except you can use the field names to access items for readability. But you
> could customize the hash, too if you wanted.
>
> Anyway -- that's in idea -- details to be fleshed out if anyone wanted to
> pursue this.
>
> -CHB
>
>
>
>
> On Sat, Mar 26, 2022 at 1:49 PM Christopher Barker 
> wrote:
>
>>
>> If I wanted to submit this as a pep (or even just submit this for a
>>> potential sponsorship), is the best way to go about it to work directly in
>>> a clone of the c/python repo, or to write a standalone library first and
>>> then after preliminary approval, add it to c/python?
>>
>>
>> You don’t need an implementation to write a PEP, and certainly not to get
>> a sponsor.
>>
>> That being said, a prototype can be helpful to work out the issues.
>>
>> You could go either way, but if it can be stand-alone, that’s easier,
>> especially for others to try it out.
>>
>> -CHB
>>
>>
>>> ___
>>> 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/Q6JTO37I42OKOAIJVBD63UL5QO3KEYLI/
>>> Code of Conduct: http://python.org/psf/codeofconduct/
>>>
>> --
>> Christopher Barker, PhD (Chris)
>>
>> Python Language Consulting
>>   - Teaching
>>   - Scientific Software Development
>>   - Desktop GUI and Web Development
>>   - wxPython, numpy, scipy, Cython
>>
>
>
> --
> Christopher Barker, PhD (Chris)
>
> Python Language Consulting
>   - Teaching
>   - Scientific Software Development
>   - Desktop GUI and Web Development
>   - wxPython, numpy, scipy, Cython
> ___
> Python-ideas mailin

[Python-ideas] Re: Add a replace method to tuples

[Ricky Teachey]

On Thu, Mar 17, 2022, 5:23 AM Steven D'Aprano  wrote:

On Thu, Mar 17, 2022 at 01:21:24AM +0900, Stephen J. Turnbull wrote:

> MRAB writes:
>
>  > I'm wondering whether an alterative could be a function for splicing
>  > sequences such as lists and tuples which would avoid the need to create
>  > and then destroy intermediate sequences:
>  >
>  >  splice(alist, i, 1 + 1, [value])
>
> Does this make sense for lists?

I don't see why not.

> I don't see how you beat
>
> newlist = alist[:]
> newlist[index_or_slice] = value_or_sequence_respectively

We know the advantages of an expression versus a statement (or pair of
statements). If this was Ruby, we could use a block:


function(arg, {newlist = alist[:];
   newlist[i] = value}, another_arg)


but it isn't and we can't.


> (instead of newlist = alist[:i] + [value] + alist[i+1:], which
> involves creating 4 lists instead of 1).

Indeed, the splice function could call a `__splice__` dunder that
specialises this for each type. It is hard to see how to write a
completely generic version.


--
Steve


Not a pro or con just an observation: since dictionaries are ordered now
people would also (somewhat reasonably, imo) want to be able to splice
them, too.
___
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/UGZRJPTHWER5FNBOZIJVEJVPS5TUQWF6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Syntax proposal of for..in..if in regular for loops

[Ricky Teachey]

I think I'm -0.5 but I have a question for the people on here smarter than
me (pretty much all):

Is there some opportunity for some kind of compiler magic when the iterable
of a for loop is fully contained in a place easily findable by the
compiler, and not spread over multiple if and for statements?

I am imagining that something like this could be magically "looked into"
and made more efficient in some way, maybe by JIT complier or something:

for x for y in range(11, 100, 3) if (y % 10) for x in range(y):
frob(x)

compared to this:

for y in range(11, 100, 3):
if (y % 10);
for x in range(y):
frob(x)

Am I instilling too much faith in the power of the complier on this Ash
Wednesday morning? ;)

---
Ricky.

"I've never met a Kentucky man who wasn't either thinking about going home
or actually going home." - Happy Chandler


On Wed, Mar 2, 2022 at 7:13 AM Dennis Sweeney 
wrote:

> I've heard "evaluation map" for a related mathematical concept: the
> natural map from X to (X -> Y) -> Y in some cartesian closed category
> (whatever that means :-), like the natural embedding of a vector space into
> its double dual space, or like this sort of eval_at function that you can
> then plug into map:
>
> def eval_at(x):
> return lambda f: f(x)
> list(map(eval_at(arg), functions))
>
> It also reminds me of a Clojure feature, where IIRC a key can be used as a
> function so that `(:key mymap)` and `(mymap :key)` both mean "the value in
> `mymap` corresponding to the key `:key`"
> ___
> 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/YFYX76ORCN4VTP2YZFWIBFIJDZ7MF7XZ/
> 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/WHV57KLYCHWJ47YV7BYOGP5YRAJCDOH4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Requirements.txt inside virtual environment

[Ricky Teachey]

On Fri, Feb 18, 2022 at 8:46 AM Vishesh Mangla 
wrote:

> Ok, then I mean that if this process could be added to the standard.
> Package install means that individually users will have to know this thing
> and they may or may not be able to find this package. I don't know what
> words to google for to find a package that serves the objective.
>

pyproject.toml  is a great way to do it. it is directly supported by pip.
check out PEP 631 . the users
don't need to know about anything else, they just pip install the package
or app like normal.

---
Ricky.

"I've never met a Kentucky man who wasn't either thinking about going home
or actually going home." - Happy Chandler
___
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/GUGIEYB73KMLAY3XGQKJ7DC2GF2SHJVO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Requirements.txt inside virtual environment

[Ricky Teachey]

I realize it's still very new to a lot of people, but doesn't
pyproject.toml solve this problem?

Just include a dependencies entry in there and use a tool like flit or
poetry.

On Fri, Feb 18, 2022, 8:24 AM Vishesh Mangla 
wrote:

> Yes, I too think they meant the same.
> ___
> 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/2YNSI5KW3G77SZNIWKPMHLESUYD65QV5/
> 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/IG7XMNHQ5E6ROFJJTQCVBX4EOGZXLXW6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Regex timeouts

[Ricky Teachey]

On Wed, Feb 16, 2022, 5:46 AM Paul Moore  wrote:

> On Wed, 16 Feb 2022 at 10:23, Chris Angelico  wrote:
> >
> > On Wed, 16 Feb 2022 at 21:01, Stephen J. Turnbull
> >  wrote:
>
> > > What I think is more interesting than simpler (but more robust for
> > > what they can do) facilities is better parser support in standard
> > > libraries (not just Python's), and more use of them in place of
> > > hand-written "parsers" that just eat tokens defined by regexps in
> > > order.  If one could, for example, write
> > >
> > > [ "Sun|Mon|Tue|Wed|Thu|Fri|Sat" : dow,
> > >   ", ".
> > >   "(?: |\d)\d)" : day,
> > >   " ",
> > >   "Jan|Feb|Mar|Apr|May|Jun|Jul|Aug|Sep|Oct|Nov|Dec" : month,
> > >   " ",
> > >   "\d\d\d\d" : year,
> > >   " ",
> > >   "\d\d:\d\d:\d\d" : time,
> > >   " ",
> > >   "[+-]\d\d\d\d" : tzoffset ]
> > >
> > > (which is not legal Python syntax but I'm too lazy to try to come up
> > > with something better) to parse an RFC 822 date, I think people would
> > > use that.  Sure, for something *that* regular, most people would
> > > probably use the evident "literate" regexp with named groups, but it
> > > wouldn't take much complexity to make such a parser generator
> > > worthwhile to programmers.
> > >
> >
> > That's an interesting concept. I can imagine writing it declaratively
> like this:
> >
> > class Date(parser):
> > dow: "Sun|Mon|Tue|Wed|Thu|Fri|Sat"
> > _: ", "
> > day: "(?: |\d)\d)"
>
> I find it mildly amusing that even this "better" solution fell victim
> to an incorrect regexp ;-)
>
> However, I do like the idea of having a better parser library in the
> stdlib. But it's pretty easy to write such a thing and publish it on
> PyPI, so the lack of an obvious "best in class" answer for this
> problem suggests that people would be less likely to use such a
> feature than we're assuming.
>
> The two obvious examples on PyPI are:
>
> 1. PyParsing - https://pypi.org/project/pyparsing/. To me, this has
> the feel of the sort of functional approach SNOBOL used.
> 2. parse - https://pypi.org/project/parse/. A scanf-style approach
> inspired by format rather than printf.
>
> Do people choose regexes over these because re is in the stdlib? Are
> they simply less well known? Or is there an attraction to regexes that
> makes people prefer them in spite of the complexity/maintainability
> issues?
>
> Paul


Long story below but TLDR: I tried to use parse for a task I worked on for
a long time, eventually had to learn regex. After using regex somewhat
regularly for a while now I concluded the power and ubiquity of it is worth
the additional cognitive load (parse only requires one to be familiar with
standard python string format syntax).

Story:

The first task I set about trying to do in python (with no practical
programming experience except for a single semester of c++ as part of a
civil engineering curriculum) was a tool to convert 2D finite element mesh
files into a file format for a niche finite element analysis program (the
program is called CANDE; it's for analysis of buried culverts and pipes).

My predecessor was creating these meshes by hand. He would literally get a
24"x36" of drafting paper and draw out his mesh and number the nodes and
elements and enter the data into the text file.

It took me eons to write something (probably 6 years!), I probably started
over from scratch at least 7, maybe 10 times. And even after all that while
I finally did arrive at something usable for myself, I never achieved my
goal of being able to package something up I can pass on to my other
colleague. When a new mesh has to be created they just ask me to do it (I
still do them occasionally).

Anyway all that to say: I remember trying to avoid learning regex for about
4 years of this. It looked too scary. One day I finally ran into a task
that parse:

https://pypi.org/project/parse/

...which I was relying heavily on, couldn't handle. I researched it and am
pretty confident that even in my relative ignorance I am/was correct about
it but being able to do it (I am racking my brain but can't remember what
that need was). This prompted me to FINALLY do a few regex tutorials and
watch some pycon videos and I came out the other end realizing that, hey,
regex isn't so bad. And it's so darn powerful that the trade off between it
being an uphill task to learn and read (at least as first) and what you are
able to do with it seems worth it.
___
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/KC2K6AX2P224SDSI6CB3P7LPWBU7M7L6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Missing expandvars equivalent in pathlib

[Ricky Teachey]

On Fri, Feb 11, 2022 at 5:44 PM Chris Angelico  wrote:

> On Sat, 12 Feb 2022 at 09:34, Ricky Teachey  wrote:
> >
> > On Fri, Feb 11, 2022 at 4:58 PM MRAB  wrote:
> >>
> >> On 2022-02-11 20:05, Ricky Teachey wrote:
> >> > Just had a thought kernel: what if there were an f-string
> mini-language
> >> > directive to grab environment variables and expand user paths? That
> >> > seems to me like it could be even more useful beyond just working with
> >> > paths.
> >> >
> >> > Maybe something like:
> >> >
> >> > f"{my_var:$}"
> >> >
> >> > This would return the same as os.path.expandvars("$my_var")
> >> >
> >> No, that would be the value of the Python variable 'my_var' with the
> >> format string "$".
> >
> >
> > well right now $ is not a valid format string for f-strings. what i'm
> suggesting is to add $ to the format spec mini-languagem and have the
> result be an expanded environment variable value.
> >
> > but you're right, i guess it would apply this to the contents of the
> variable my_var, not the STRING my_var. so maybe the spelling would need to
> use a nested quotation, like this:
> >
> > f"{'my_var':$}"
> >
> > this would be the same as os.path.expandvars("$my_var")
> >
>
> Why shoehorn it into f-strings? Even worse: Why should f-strings fetch
> external information in such a hidden way?
>
> One thing I'm not fully aware of here is what precisely is wrong with
> the status quo. Are you looking for a method instead of a function? Do
> you need something that takes a Path and returns a Path? The existing
> os.path.expandvars will happily accept a Path and return a str:
>
> >>> import pathlib, os.path
> >>> pathlib.Path("$HOME/cpython/Grammar/python.gram")
> PosixPath('$HOME/cpython/Grammar/python.gram')
> >>> os.path.expandvars(pathlib.Path("$HOME/cpython/Grammar/python.gram"))
> '/home/rosuav/cpython/Grammar/python.gram'
> >>> type(_)
> 
>
> I'm confused, since anything involving f-strings clearly has nothing
> to do with pathlib (other than in the trivial sense that you could
> expand vars before constructing a Path), but the OP was very
> definitely talking about Path objects.
>
> ChrisA
>

yes but path objects are usually constructed from a string, and you could
support path objects easily in the f-string using my suggested ~ format
specifier:

Path(f"{my_path_obj:~}")

granted this is a bit weird since you're going from a path obj, to a
string, and back to a path obj again.

i thought of the idea because Serhiy Storchaka brought up the point that
the two expand methods that currently live in os.path have more to do with
strings than they do paths. because of this f-strings seemed to me like a
potentially convenient place to put this functionality. doesn't feel like a
shoehorn at all.

but i suppose in practice, producing an expanded path like above doesn't
seem all that useful. so it's an idea in search of a use case, which means
is probably isn't a very good idea.

---
Ricky.

"I've never met a Kentucky man who wasn't either thinking about going home
or actually going home." - Happy Chandler
___
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/DPKBNOKG4TO5I326ZCWPXRM4W2BUIQHP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Missing expandvars equivalent in pathlib

[Ricky Teachey]

On Fri, Feb 11, 2022 at 4:58 PM MRAB  wrote:

> On 2022-02-11 20:05, Ricky Teachey wrote:
> > Just had a thought kernel: what if there were an f-string mini-language
> > directive to grab environment variables and expand user paths? That
> > seems to me like it could be even more useful beyond just working with
> > paths.
> >
> > Maybe something like:
> >
> > f"{my_var:$}"
> >
> > This would return the same as os.path.expandvars("$my_var")
> >
> No, that would be the value of the Python variable 'my_var' with the
> format string "$".
>

well right now $ is not a valid format string for f-strings. what i'm
suggesting is to add $ to the format spec mini-languagem and have the
result be an expanded environment variable value.

but you're right, i guess it would apply this to the *contents *of the
variable my_var, not the STRING my_var. so maybe the spelling would need to
use a nested quotation, like this:

f"{'my_var':$}"

this would be the same as os.path.expandvars("$my_var")

---
Ricky.

"I've never met a Kentucky man who wasn't either thinking about going home
or actually going home." - Happy Chandler
___
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/M73QONQ3HHC2WZN4R657SUDWHWM5L6VK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Missing expandvars equivalent in pathlib

[Ricky Teachey]

Just had a thought kernel: what if there were an f-string mini-language
directive to grab environment variables and expand user paths? That seems
to me like it could be even more useful beyond just working with paths.

Maybe something like:

f"{my_var:$}"

This would return the same as os.path.expandvars("$my_var")

I am not sure about user name expansion though. Maybe something like:

f"{user:~}"

...would return the user directory, and this:

f"{:~}"

...would give the same result as os.path.expanduser("~")

---
Ricky.

"I've never met a Kentucky man who wasn't either thinking about going home
or actually going home." - Happy Chandler


On Fri, Feb 11, 2022 at 2:04 PM Paul Moore  wrote:

> On Fri, 11 Feb 2022 at 16:37, Christopher Barker 
> wrote:
> >
> > On Fri, Feb 11, 2022 at 12:28 AM Serhiy Storchaka 
> wrote:
> >>
> >> expandvars() does not operate on paths, it operates on strings and
> >> bytestrings. There is nothing path-specific here. Expanding environment
> >> variables consists of three distinct steps:
> >
> > sure -- but it does live in os.paths now, the docs talk about paths, and
> it is useful for paths -- so it seems a fine idea to have that
> functionality in pathlib.
>
> One way that tying it to paths is bad is that it ignores the path
> structure. If environment variable a is "d1/f1" and b is "d2/f2" then
> "${a}x${b}" is "d1/f1xd2/f2", which could be very confusing to someone
> who sees the value of b and expects the result to be a file in a
> directory called d2. Yes, I know that the documentation could make
> this clear (the docs in os.path don't, BTW) and I know that it's no
> different than the os.path version, but adding an expandvars method to
> pathlib feels like throwing good money after bad...
>
> Let's leave it where it is and keep the status quo, or fix it
> *properly* and put it somewhere more logical like shlex. Personally I
> don't use it that often, so I'm fine with just leaving it alone.
>
> Paul
> ___
> 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/2XSYXAFLMMVGJDYJYRM2CDZO2WV5YDX6/
> 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/IGI5FKZAR62T63JKEC4JTOCRXLVJGTT2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: "frozen" operator Re: Revisiting a frozenset display literal

[Ricky Teachey]

On Fri, Jan 21, 2022 at 6:57 AM Chris Angelico  wrote:

> On Fri, 21 Jan 2022 at 22:52, Ricky Teachey  wrote:
> >
> > On Fri, Jan 21, 2022 at 5:04 AM Steven D'Aprano 
> wrote:
> >>
> >> On Fri, Jan 21, 2022 at 11:18:27AM +1100, Cameron Simpson wrote:
> >>
> >> > Paired with a __freeze__ dunder method, this applies to any type, not
> >> > just sets. (Where appropriate of course.)
> >> >
> >> > So:
> >> >
> >> > |{1,2,3}|   frozen set
> >> > |[1,2,3]|   tuple!
> >> > |any-iterable|  tuple!
> >> > |{1:2, 3:4}|frozen dict
> >>
> >> A frozen "any iterable" is not necessarily a tuple.
> >>
> >> For example, a frozen binary tree should probably keep the tree
> >> structure and methods; a frozen dict.keys() should be a frozen set; and
> >> its not clear what a frozen iterator should do. Should it run the
> >> iterator to exhaustion? Seems odd.
> >>
> >> What about non-collections? What's a frozen re.MatchObject?
> >>
> >>
> >> --
> >> Steve
> >
> >
> > lord have mercy, what a can of worms this could end up being!:
> >
> > frozen iostream
> > frozen property
> > frozen function object
> > frozen module object
> > frozen iterator
> > frozen datetime
> >
>
> Let's be fair here... The idea of freezing is to make it hashable, so
> there's no point talking about freezing a function, module, or
> datetime, since they are already hashable. Don't saddle the proposal
> with issues it doesn't have :)
>
> (Technically this applies to an re.Match object too, actually,
> although I had to check to be sure. I've never once wanted to use one
> as a dict key. In contrast, I most certainly *have* used functions as
> dict keys, and it's safe and dependable.)
>
> ChrisA
>

Great point! I learned something.

---
Ricky.

"I've never met a Kentucky man who wasn't either thinking about going home
or actually going home." - Happy Chandler
___
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/NY55JUHLGVNA43FS4UBGJMBULCKVG4TM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: "frozen" operator Re: Revisiting a frozenset display literal

[Ricky Teachey]

On Fri, Jan 21, 2022 at 5:04 AM Steven D'Aprano  wrote:

> On Fri, Jan 21, 2022 at 11:18:27AM +1100, Cameron Simpson wrote:
>
> > Paired with a __freeze__ dunder method, this applies to any type, not
> > just sets. (Where appropriate of course.)
> >
> > So:
> >
> > |{1,2,3}|   frozen set
> > |[1,2,3]|   tuple!
> > |any-iterable|  tuple!
> > |{1:2, 3:4}|frozen dict
>
> A frozen "any iterable" is not necessarily a tuple.
>
> For example, a frozen binary tree should probably keep the tree
> structure and methods; a frozen dict.keys() should be a frozen set; and
> its not clear what a frozen iterator should do. Should it run the
> iterator to exhaustion? Seems odd.
>
> What about non-collections? What's a frozen re.MatchObject?
>
>
> --
> Steve
>

lord have mercy, what a can of worms this could end up being!:

frozen iostream
frozen property
frozen function object
frozen module object
frozen iterator
frozen datetime

i mean, i could certainly imagine rational (maybe even useful...?) ideas
for ALL of these. can you imagine the endless discussion about what to do
with the shiny new frozen operator, for every object under the sun?
obviously it would to nothing by raise an error by default. but people
would be asking to freeze everything and there would be mountains of ideas
threads and it would never end.

i'm not saying that reason means we don't have such an operator, but it
seems to me this just shows the decision on PEP 315 was the right one. why
have such a general operator, that could conceivably- and will be endlessly
requested and argued- be expanded to apply MANY things that even though
YAGNI for nearly all of them, when the only REAL need is only for a
frozenset?

---
Ricky.

"I've never met a Kentucky man who wasn't either thinking about going home
or actually going home." - Happy Chandler
___
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/K5KAKGI5T6XTKPYC5IXA4LXJGDWDTHL6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Revisiting a frozenset display literal

[Ricky Teachey]

On Thu, Jan 20, 2022 at 3:35 AM Stephen J. Turnbull <
stephenjturnb...@gmail.com> wrote:

> Christopher Barker writes:
>
>  > If this does all come to pass, then:
>  >
>  > s = {3,8,2}.frozen()
>  > will be slightly faster, in some case, than
>  > s = frozenset({3,8,2}
>  >
>  > but the result would be the same.
>  >
>  > There are plenty of tricks to in python to get a touch more performance,
>  > this would just be one more
>  > and frankly pretty rare that it would make an noticable difference at
> all.
>  >
>  > +1 on this
>  > +0 on f{}
>  > -1 on making frozenset a keyword
>
> Stated better than I could, expresses my feelings exactly.  Sticking
> to integers (in floats I'd be less than -0 on f{}), I'll go with
> Chris's ratings, too.
>
> Steve
>

Another agreement with Chris' ratings:

+1 for .frozen()
+0 on f{}
-1 on keyword for frozenset

But that still leaves the literal for the empty set as a problem. I'm still
not sure what I think about {,} as an empty set. I tend to think it looks
like "empty dictionary" and so could be confusing.

Perhaps something like set.frozen() or set().frozen() could be optimized?

---
Ricky.

"I've never met a Kentucky man who wasn't either thinking about going home
or actually going home." - Happy Chandler
___
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/VQANC4SH4VII6F5Y35SWWF5YKVHG4JN2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Revisiting a frozenset display literal

[Ricky Teachey]

Why does it need to be called at all?

{1, 2, 3}.frozen

Or even:

{1, 2, 3}.f


On Wed, Jan 19, 2022, 6:28 AM Steven D'Aprano  wrote:

> On Wed, Jan 19, 2022 at 07:20:12AM +, Ben Rudiak-Gould wrote:
> > My preferred syntax for a frozenset literal would be something like
> >
> > {1, 2, 3}.freeze()
> >
> > This requires no new syntax, and can be safely optimized at compile time
> > (as far as I can tell).
>
> I like that, it is similar to a proposal for docstrings:
>
> https://bugs.python.org/issue36906
>
> This would be safe to optimize at compile time, so long as the contents
> of the set were all literals. And for implementations that didn't
> optimize at compile time, it would be no worse than the situation now.
>
> Perhaps a better name would be "frozen()` since that doesn't imply
> an in-place operation like "freeze" does.
>
>
>
> --
> Steve
> ___
> 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/B3GTIXHL6QBJP5BIBAPP2TUQ2EO3GNPO/
> 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/TEBK2PJAKKWE52FE7XJVC4WEFZKWRUGD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Revisiting a frozenset display literal

[Ricky Teachey]

On Tue, Jan 18, 2022 at 10:02 AM Joao S. O. Bueno 
wrote:

> >  but I don't think we should underestimate the cost of even this small
> complexity increase in the language.
>
> Actually, I think _maybe_ in this case the "complexity increase" cost is
> _negative_. People might waste
> more time looking for a way of spelling a frozenset literal than just
> filling in "frozenset()".
> I for one, even knowing that the cost of writing "frozenset({1,2,3})" is
> negligible, would
> "feel" better there was a way to spell that without the needless
> conversions.
>
> That said, an appropriate prefix for the {} just as we do for strigns
> would be nice, and
> I disagree that it would be a significant source for "bugs". The "@{" is a
> nice
> way out if people think "f{}" would be too close to "f()". And "<1,2,3>"
> just for frozensets
> are indeed overkill. We already do "literal prefixing" with `"` after all.
> and formally extending this
> prefix usage as needed for other literals seems like a nice path.
> But, as far as bikeshedding go, we also have "literal sufixing" (2.0j
> anyone?)- maybe
> "{1,2,3}f" ?
>

I have been following along with not much to comment but this response
sparked something in me.

After reading all the viewpoints I think I would be +1 on the basic idea,
and a +1 on the postfix/suffix syntax just suggested... the other syntaxes
I'm more of +0.5

I like the way the suffix FLOWS with the act of writing the program. When I
write a set, I am primarily focused on *what I am going to put in it*, and
whether or not it should be mutable is kind of a later thought/debate in my
head after I have established what it contains.

As a dumb example, if my task at hand is "I need to create a bag of sports
balls", I am mostly thinking about what goes into that bag at first, so I
will write that first:

   >>> {Ball("basketball"), Ball("soccer"), Ball("football"), Ball("golf")}

Now I get to the end of that line, and I then sort of naturally think "ok
does it make sense to freeze this" after i know what is in it.  With the
postfix syntax, I then either type the f:

   >>> {Ball("basketball"), Ball("soccer"), Ball("football"), Ball("golf")}f

...or not. With a prefix type syntax, or a smooth bracket syntax, either:

A. it takes slightly more "work' at this point to "convert" the set to a
frozenset, OR
B. i have to think about ahead of time-- before i have actually written
what is in the set- whether it will be frozen, or not.

In contrast, when you are deciding whether to write a list vs a tuple, you
are deciding between two things that are fundamentally far more different
IDEAS than a "bag of things, frozen or unfrozen". A list is very often more
of an open ended stack than it is "an unfrozen tuple". A tuple is very
often much more of an object that can be used as a dictionary key, or a
member of a set, than it is a container of things (of course, it is a
container of things, too). These differences make is a lot easier to
choose, ahead of time, which one makes sense before you have even written
the line of code.

Maybe I'm making too much of this, but I really like the idea of deciding
at the END of the set literal whether to tack on that "f".

---
Ricky.

"I've never met a Kentucky man who wasn't either thinking about going home
or actually going home." - Happy Chandler
___
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/T7X3XI3ZQMQIQEMGPSTGLAFOCMXKWWFV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Runtime-accessible attribute docstrings – take 2

[Ricky Teachey]

On Tue, Dec 14, 2021, 9:49 PM Paul Bryan  wrote:

> Interesting. Some apparent downsides:
>
> - doesn't apply to class attributes
> - objects with `__slots__` can't dynamically add attributes
>

Also doesn't apply to module level members.

To my mind these are significant downsides. And it also represents yet
another way people are documenting attributes in the wild.

Here's another I learned if which is supported by sphinx autodoc:

comment tag colon docstring
attribute statement

Example:

#: spam
x = 1

Using this style, the documentation has to come before the attribute.

Obviously- unless VERY big change is introduced- this "docstring" will
never be runtime accessible since it's a comment. But it does represent yet
another way people are doing documentation in the wild.

Sigh.

Rick.
___
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/NTYRIIDYNJUUKT4PCVJEHOBFQDOQ32JP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Runtime-accessible attribute docstrings – take 2

[Ricky Teachey]

On Tue, Dec 14, 2021 at 10:23 AM Joao S. O. Bueno 
wrote:

> Just a short one, for everyone agreeing type.Annotated does the job,
> but thinks we need new syntax, because it is verbose:
>
> You can already do:
>
> from typing import Annotated as A
>
> And:
>
> attr: A[type, "docstring goes here"]
>
> I see no need for any new syntax.
>
> (and maybe adding typing.Docstring for the cases when one
> just wants the docs, but no type annotation)
>

You're not wrong exactly. But there has been a desire to reduce the need
for typing module imports in general, and I think eliminating the need to
import Annotation for this specific use case might have merit, if is
becomes blessed as The Way, and if we think it is a good idea to say to
people "hey! providing docstrings for members is a really good practice,
and so we're making is super duper easy and standardizing it!" (just as we
encouraged people to provide docstrings in the past for modules and classes
by making that syntax dead simple to use).

---
Ricky.

"I've never met a Kentucky man who wasn't either thinking about going home
or actually going home." - Happy Chandler
___
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/H5NIEA24YOZOY6TUFIRAYV4IK5FNYQQJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Runtime-accessible attribute docstrings – take 2

[Ricky Teachey]

I'll go ahead and throw this out there: I was talking to a friend about
this and he pointed out something simple but astute.

Will this be expected to work?

class C:
x: Annotated [Any, "spam"]

help(C.x)

Obviously it shouldn't as things stand now because that's an
AttributeError.

But if I'm mucking about in the interpreter and I want to see the docstring
of a runtime defined (but not import time) attribute, it would be kind of
nice if it would work. And it seems reasonable to try and create a way for
it to work.
___
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/7OJISJNCVKIFNA5LYRBHL7C2RLK3B5FI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Runtime-accessible attribute docstrings – take 2

[Ricky Teachey]

On Sun, Dec 12, 2021, 1:57 AM Steven D'Aprano  wrote:

On Sun, Dec 12, 2021 at 12:38:06AM -0500, Ricky Teachey wrote:

> But Steve, since the most utilized documentation tool in the python
> universe, sphinx, doesn't look at Annotated

Yet.

> or in the lowercase-annotation part of an expression

Yet.

> for this and instead looks at a bare string below the
> member definition, and since I presume it had been doing this for a long
> time (before Annotated was added not long ago, and probably before the
> annotation too?), doesn't this mean that right now there are at least
three
> competing ways being used to provide attribute docstrings?

And before we had PEP 484 there were multiple competing and
incompatible conventions for putting type hints in docstrings.

https://www.python.org/dev/peps/pep-0484/

There are:

- Epytext (Javadoc style)
- ReST (Sphinx)
- Googledoc
- Numpydoc

although some of them may no longer be widely used.

https://stackoverflow.com/questions/3898572/what-are-the-most-common-python-docstring-formats

https://www.adrian.idv.hk/2018-02-18-docstring/

Static and runtime tools that wanted to get type hints had to guess the
format and parse the docstring to get the types. Who still does that?

If dataclasses, and other classes, move to using Annotated and
__attrdoc__ for docstrings, the tools will follow. Runtime tools will
look at the dunder, static tools will look at the annotation directly.

**Which they will have to do anyway** if we add the convention that
string literals following an assignment get recorded in __attrdoc__.
Runtime tools will want to look in the dunder, not parse the source
code. And static tools which aren't Sphinx will need to be adjusted to
look at the string literals.

So either way the tooling has to change.

Sphinx is not the decider here. I dare say that they will want to
continue supporting bare strings into the indefinite future, but new
tools, and those with weaker backwards-compatibility constaints, will
surely prefer to extract docstrings from __attrdoc__ than parsing the
source code.


> As far as using the lowercase-annotation for the docstring: in a world of
> more and more type hinted python (to be clear: I don't always use type
> hints but I do like this world), if you want to make you don't create a
> problem later, using the annotation slot for your docstring:
>
> x: "spam"
>
> ... isn't really an option.

Of course it is. Just decorate your class with @no_type_hints.


> - without an official blessed agreement that the existing Annotated
feature
> ought to be used for docstrings, there is little reason for other 3rd
party
> help/documentation tools to look in that location for these docstrings

All it takes is literally one stdlib class to start doing it officially,
and people will pay attention.


> I just think there's more to do here than add a decorator.

That depends on whether you mean, what do *we* need to do get the ball
rolling, or what does the entire Python ecosystem need to do to
transition to the day that every tool and library is actively using
attribute docstrings both statically and at runtime?

Of course the second part is a bigger job.

But for the first, we can either (1):

* bikeshed this for another six ~~months~~ weeks;
* get at least one core dev to agree to sponsor a PEP;
* write a PEP;
* bikeshed some more;
* wait for the Steering Council to hopefully accept the PEP;
* modify the interpreter;
* wait for the new version to be available;

or we can (2)

* implement and support the feature today;

to get to the point that external tools can start using it.

I'm not kidding, if somebody cared enough to do this, they could
probably have a patch for dataclasses to support this within a couple of
hours and a plugin for Sphinx within a day.

(Spoken with the supreme confidence of somebody who knows that he will
absolutely not have to do either.)

As far as I am concerned, this is exactly the sort of use-case that
Annotated was invented for. Docstrings are metadata. Annotated is for
attaching metadata to an annotation that is associated with some
variable. Done and done.

--
Steve


I agree. I think adding something like __attrdoc__ is a very good idea.
Would like to see it in all classes, personally, and then have help() look
there. But starting with dataclasses seems like a logical place and might
get us started on that goal.

And if we start this with dataclasses and it gets expanded, none of this
would slam the door on the idea of using a bare string after the definition
as sugar for populating __attr_doc__. In fact if there's any hope that
would ever happen, first people would need to find themselves using
Annotated far more often, and get tired of having to use the longish syntax
with an import and agree on such a syntax change.
___
Python-ideas mailing list -

[Python-ideas] Re: Runtime-accessible attribute docstrings – take 2

[Ricky Teachey]

On Sat, Dec 11, 2021, 10:58 PM Steven D'Aprano  wrote:

> On Sat, Dec 11, 2021 at 05:02:39PM -0800, Christopher Barker wrote:
> > On Sat, Dec 11, 2021 at 3:03 PM Steven D'Aprano 
> wrote:
>
> > > Didn't we decide there was an existing feature for this, no need for
> > > new syntax?
>
> > Well, no. In fact, you could always put anything you wanted into an
> > annotation:
>
> Right, and we want to put a documentation string in it! :-)
>
>
> > Anyway, take a look at the docs for Annotated:
> >
> > https://docs.python.org/3/library/typing.html#typing.Annotated
> >
> > It has a number of possible unspecified uses, but fundamentally, it's
> about
> > the adding information to the type, not to the attribute -- e.g. not
> really
> > intended for docstrings.
>
> I don't think that the docs argue against this. Annotated is documented
> as the way to put arbitrary metadata into an annotation. What you do
> with it is up to the consumer of the metadata.
>
> The docs talk about this associating the metadata with the type, but
> that's because this is the *typing* module and *type* hints are still
> the primary use-case for annotations.
>
> And despite what the docs say, the metadata is actually, literally,
> associated with the variable (or its name at least). The annotation that
> gets stored in __annotations__ is **not**
>
> {T: "metadata"}
>
> as a naive reading of the docs might trick you into believing, but
>
> {"var": Annotated[T, "metadata"]}
>
>
> In any case, we can still use annotations for anything we like, and
> while typing is definitely and certainly the primary use for them, there
> will always be a way to opt-out. (Just don't run mypy!)
>
> Don't need type hints at all? Great, put your doc string as the
> annotation.
>
> μ: 'Number of steps from x0 to the start of the cycle.'
> λ: 'Length (period) of the cycle.'
> y: 'Value of f at the start of the cycle.' = None
>
> You might want to annotate the class with `no_type_check` if there is
> any chance the user might want to run mypy over your module, but that's
> entirely up to you.
>
> You do want type hints? Great, use Annotated. If there's an attribute
> that you don't want to give a type hint to, just use Any. (A small price
> to pay for using an existing feature, instead of waiting until Python
> 3.11 or 3.27 when it gets added to the core language.)
>
> μ: Annotated[int,
>  'Number of steps from x0 to the start of the cycle.']
> λ: Annotated[int, 'Length (period) of the cycle.']
> y: Annotated[Any,
>  'Value of f at the start of the cycle.'
>  ] = None
>
> No new syntax required. No bare strings floating around. You can
> generate the doc strings dynamically, they don't have to be literals.
>
> lunch: Annotated[Meal, ' '.join(['spam']*SPAM_COUNT)]
>
>
> > Sure, typing.Annotated *could* be used that way, but I don't think we can
> > say that the problem is solved.
>
> I think that from a language standpoint, we absolutely can say that the
> problem is solved. We don't need new syntax.
>
> We *might* want to standardise on a decorator or other tool to extract
> those docstrings, possibly sticking them in a new __attrdoc__ dunder.
> Being a dunder, we should get the core dev's approval for this, even if
> it is a third-party tool that uses it.
>
> (I assume we don't already use __attrdoc__ for something?)
>
> If the first use of this is dataclasses, then that would be de facto
> core dev approval.
>
> So we have a tool that takes an annotation:
>
> var: Annotated[T, docstring, *args]
>
> extracts out the docstring to an __attrdoc__ dunder:
>
> # Class.__attrdoc__
> {'var': docstring}
>
> and removes the annotation from the annotation:
>
> # Class.__annotation__
> {'var': Annotated[T, *args]}  # or just T if *args is empty?
>
> Dataclasses can automatically apply this tool (subject to backwards
> compatibility constraints), or we can apply it as a decorator to any
> other class we want.
>
> So we've gone from the *hard* problem of making a language change (new
> syntax, build the functionality into the interpreter) to the *easy*
> problem of writing a decorator.
>
>
> > Heck you could just as easily provide a tuple for the annotation:
> >
> > In [17]: class C:
> > ...: x: ("Doc string", int) = 123
> > ...:
>
>
> Sure, annotations can be anything you like. But external static typing
> tools may not support this, and will be confused or break. Same for
> third-party runtime tools.
>
> Best practice is to stick as closely to the standard type-hinting
> behaviour as you can, or to completely opt-out with no_type_hints.
>
>
> > The use cases for annotations are a bit up in the air at the moment --
> see
> > the ongoing discussion on python-dev. But I don't think there's any doubt
> > that any future endorsed use of them will be compatible with static
> typing
> > (if not restricted to it), so extending the use of annotations for
> > docstrings w

[Python-ideas] Re: Runtime-accessible attribute docstrings – take 2

[Ricky Teachey]

On Sat, Dec 11, 2021, 1:19 PM Christopher Barker 
wrote:

> 
>
> Where/how should class attribute doc strings be stored?
>
> Tacked on to the class __doc__ ?
>
> Another dict?
>
> __attr_doc__
>
> Added to __annotaions__ ?
>
> Something else?
>
> If they are to be available at run time, they need to go somewhere…
>
> -CHB
>
>>
>> --
> Christopher Barker, PhD (Chris)
>

The __annotations__ already exists. Is that a point in favor? If the syntax
could become sugar for creating an Annotated object in __annotations__,
this would be a pretty convenient location to find them.

On the other hand, not every type hinted variable will have a docstring. It
might be inconvenient to have them there only. It seems like storing them
in a so called __attr_doc__ might be the most straightforward thing to do.

If that were done, does it matter that the contents of __attr_doc__ and
__annotations__ are not coupled? The strings might need to be modified.
Would be inconvenient to have to modify two places in such a situation.
___
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/7S4RM4APDP4FC7L6DBHJU7GAHES3ABPV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Runtime-accessible attribute docstrings – take 2

[Ricky Teachey]

On Sat, Dec 11, 2021, 12:57 AM Stephen J. Turnbull <
stephenjturnb...@gmail.com> wrote:

Simão Afonso writes:
 > On 2021-12-10 12:20:44, Ricky Teachey wrote:
 > > I meant to ask about a (global) module member, not the module docstring
 > > itself. Like MY_GLOBAL below:
 > >
 > >  """This is the module docs"""
 > >
 > >  MY_GLOBAL = None
 > >  """MY_GLOBAL docs"""
 > >
 > > Is this "global docstring" recognized by Sphinx as a docstring, too?
 >
 > My bad.
 >
 > Double checked and that's right, it is recognised as such.

To my mind Sphinx is sufficiently widely used that this settles the
"above or below" question.

Steve


I agree.

Even with this convention one could still accomplish separating the
documentation section from the definition section, like:

class Steel:
"""A simple material model of steel."""

# parameters
E_s: float
"the linear elastic modulus"

nu: float
"the poisson's ratio"

gamma: float
"the density"

# values
E_s = 29e6  # ksi
nu = 0.3
gamma = 490  # lbs per cu ft

As has already been observed, we already have something LIKE an attribute
docstring, which is an Annotated type hint object.

Should the bare docstring below the member become sugar for creating an
Annotated type hint?

x = 1
"spam"

Would then be equivalent to:

x: typing.Annotated[typing.Any, "spam"]

This seems really nice to me.
___
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/LO7KDBDFKKDI5XJJ7GE227PBTTM3D7NN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Runtime-accessible attribute docstrings – take 2

[Ricky Teachey]

On Fri, Dec 10, 2021 at 11:46 AM Simão Afonso <
simao.afo...@powertools-tech.com> wrote:

> On 2021-12-10 08:20:25, Ricky Teachey wrote:
> > Very very interesting that Sphinx already treats a bare string under the
> > parameter as documentation! I had no idea. Does it do the same thing at
> the
> > module level?
>
> Yes.
>
> > $ cat module.py
> > """This is the module docs"""
> >
> > class CLS:
> >   """CLS docs"""
> >
> >   attr: int
> >   """CLS.attr doc"""


I meant to ask about a (global) module member, not the module docstring
itself. Like MY_GLOBAL below:

 """This is the module docs"""

 MY_GLOBAL = None
 """MY_GLOBAL docs"""

 class CLS:
   """CLS docs"""

   attr: int
   """CLS.attr doc"""

Is this "global docstring" recognized by Sphinx as a docstring, too?

---
Ricky.

"I've never met a Kentucky man who wasn't either thinking about going home
or actually going home." - Happy Chandler
___
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/643W2H5YJZN7G5AAQUE4HL7VCAERVEUF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Runtime-accessible attribute docstrings – take 2

[Ricky Teachey]

On Fri, Dec 10, 2021, 6:08 AM Simão Afonso 
wrote:

> On 2021-12-09 12:47:28, Paul Bryan wrote:
> > On Thu, 2021-12-09 at 19:01 +, Simão Afonso wrote:
> > > I'm using docstrings bellow the attributes (analogous to functions
> > > and
> > > classes), I think it works well.
> > > It helps with distinguishing the class docstring from the arguments.
> >
> > I think you'll find on close inspection that those strings don't "go
> > anywhere" (i.e. they're not in help documentation, they're not
> > introspectable.)
>
> Wow, that's right, I stand corrected.
>
> They do appear on Sphinx auto-generated documentation, so I assumed it
> was a regular annotation, like classes and functions.
>

Very very interesting that Sphinx already treats a bare string under the
parameter as documentation! I had no idea. Does it do the same thing at the
module level?

>
___
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/U5D53FEEDHL6WXCQHTCOSTR3FTYQAVF6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Runtime-accessible attribute docstrings – take 2

[Ricky Teachey]

On Thu, Dec 9, 2021 at 3:23 PM Ricky Teachey  wrote:

> On Thu, Dec 9, 2021 at 3:08 PM Christopher Barker 
> wrote:
>
>> On Thu, Dec 9, 2021 at 11:08 AM Simão Afonso <
>> simao.afo...@powertools-tech.com> wrote:
>>
>>> Shouldn't typing be encouraged on dataclasses, at least?
>>
>>
>> Typing shouldn’t be encouraged for any particular class, nor the language
>> itself. Typing policy is a matter for the project/organization to decide.
>>
>> But Annotations are required by dataclasses in any case. That’s how the
>> decorator identifies fields.
>>
>> The contents of those annotations are up to the user.
>>
>> -CHB
>>
>>
> Since not everyone uses dataclasses and to avoid confusion: what you mean
> here is that type HINTS are required by dataclasses, not Annotations. An
> Annotated is a type of type hint that contains an annotation, which we're
> loosely calling a member docstring in this thread (currently, a "member
> docstring" is not really a thing that exists, unless you count a comment or
> a string nearby the statement creating the member).
>

A correction to my correction (Chris Barker very kindly replied to me
off-list about it; what a mensch): type hints aren't required in a
dataclass. All that is required is *something* in the "type hint slot" of
the expression, and that something is often (officially?) called an
annotation.

So we have at least 3 meanings of annotation/annotate/annotated possibly at
work in this thread (what fun):

   1. an annotation (the slot where type hints usually go these days, but
   really, you can put anything there even when constructing a dataclass),
   2. the Annotated type hint type, and
   3. the annotation that is the second argument of the Annotated brackets
   operator. How confusing!

---
Ricky.

"I've never met a Kentucky man who wasn't either thinking about going home
or actually going home." - Happy Chandler
___
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/26WOAIZF4Y57XTXRKYSOBBETHPKKG5H7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Runtime-accessible attribute docstrings – take 2

[Ricky Teachey]

On Thu, Dec 9, 2021 at 3:08 PM Christopher Barker 
wrote:

> On Thu, Dec 9, 2021 at 11:08 AM Simão Afonso <
> simao.afo...@powertools-tech.com> wrote:
>
>> Shouldn't typing be encouraged on dataclasses, at least?
>
>
> Typing shouldn’t be encouraged for any particular class, nor the language
> itself. Typing policy is a matter for the project/organization to decide.
>
> But Annotations are required by dataclasses in any case. That’s how the
> decorator identifies fields.
>
> The contents of those annotations are up to the user.
>
> -CHB
>
>
Since not everyone uses dataclasses and to avoid confusion: what you mean
here is that type HINTS are required by dataclasses, not Annotations. An
Annotated is a type of type hint that contains an annotation, which we're
loosely calling a member docstring in this thread (currently, a "member
docstring" is not really a thing that exists, unless you count a comment or
a string nearby the statement creating the member).

On Thu, Dec 9, 2021 at 2:01 PM Simão Afonso <
simao.afo...@powertools-tech.com> wrote:

> I'm using docstrings bellow the attributes (analogous to functions and
> classes), I think it works well.
> It helps with distinguishing the class docstring from the arguments.
>
> On 2021-12-08 13:25:55, Ricky Teachey wrote:
> > On Wed, Dec 8, 2021 at 1:20 PM Paul Bryan  wrote:
> > > I believe a Annotated[..., str] could become an attribute docstring if
> by
> > > consensus we deem it to be so. I can't see any disadvantages, perhaps
> save
> > > for the verbosity of `Annotated`. It certainly seems like an advantage
> to
> > > use an existing mechanism rather than define a new one that would
> appear to
> > > require changes to the interpreter.
> >
> > I think this would be better than nothing. But it is a little verbose.
> And
> > it requires you to supply the type hint.
> >
> > I use type hinting, but I don't want to use it every time I provide an
> > Annotation/docstring.
>
> In this case, why not use the current behaviour of putting the docstring
> below the attribute?
>
> Shouldn't typing be encouraged on dataclasses, at least?


What is meant here by "the current behaviour"? Member docstrings are
currently not a feature supported by the language. If you like putting a
string under the member definition for reference, that sounds really nice.
But baking it into the language so that the docstring has to come right
after the member seems limiting to me.

This location requirement makes a lot of sense for modules and classes. But
for class members, I'd really like to be able to organize the docstring
location in a more flexible way, like (using Steven's proposed syntax):

class Steel:
"""A simple material model of steel."""

# parameters
modulus :: "the linear elastic modulus"
nu :: "the poisson's ratio"
gamma: "the density"

# values
modulus: float = 29e6  # ksi
nu: float = 0.3
gamma: float = 490  # lbs per cu ft



---
Ricky.

"I've never met a Kentucky man who wasn't either thinking about going home
or actually going home." - Happy Chandler
___
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/KZ5NW2XG2AJP5R5MEQNBIPWVA4OQGLTN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Runtime-accessible attribute docstrings – take 2

[Ricky Teachey]

On Thu, Dec 9, 2021 at 12:12 AM Paul Bryan  wrote:

> On Thu, 2021-12-09 at 12:32 +1100, Steven D'Aprano wrote:
>
> On Wed, Dec 08, 2021 at 09:45:35AM -0800, Paul Bryan wrote:
>
> I propose there is already a viable option in typing.Annotated.
> Example:
>
> @dataclass
> class InventoryItem:
> """Class for keeping track of an item in inventory."""
>
> name: Annotated[str, "Short name of the item."]
> unit_price: Annotated[float, "Price per unit in dollar."]
> ...
>
>
> Oh nice! Guido's time machine strikes again.
>
> So dataclasses could recognise Annotated and populate `__attrdoc__`.
>
>
> Indeed.
>
> Should all classes do the same? How about top level module variables?
>
>
> If we started with dataclass, it could be performed in the dataclass
> decorator and make_dataclass functions. I think this would be low-hanging
> fruit compared to classes and modules.
>

Again: better than nothing. But I'd really like to see this for all classes.

I suggest that if a proposal like this is accepted, the help() output for
classes and modules should have a new section added containing the member
docstring information; it essentially would insert the member information
to the end of the main docstring WHEN DISPLAYED (not suggested attaching it
permanently as part of the docstring). This new section would appear
directly beneath the module/class docstring when using help. Additionally,
other help()-ilke tools (such as the ipython ? operator) should be
encouraged to concatenate the member docstring information directly below
the class/module docstring when printing out help-like information.

To illustrate how things currently stand, here's a current, sort of
minimally complicated class definition (class B) with some annotations:

In [1]: from typing import Annotated

In [2]: class B:
   ...: """Docstring for the B class."""
   ...:
   ...: a: Annotated[int, "here is what i'd call a medium length
docstring"]
   ...: b: Annotated[str, "short docstring"]
   ...:

and here is the help(B) output that i get (Windows command line):

In [3]: help(B)
Help on class B in module __main__:

class B(builtins.object)
 |  Docstring for the B class.
 |
 |  Data descriptors defined here:
 |
 |  __dict__
 |  dictionary for instance variables (if defined)
 |
 |  __weakref__
 |  list of weak references to the object (if defined)
 |
 |  --
 |  Data and other attributes defined here:
 |
 |  __annotations__ = {'a': typing.Annotated[int, "here is what i'd call
a...

The member annotations aren't very discoverable this way... you can't even
see all of the first one. If it is agreed that Annotated should be The
Blessed Way to annotate members, this needs to be improved.

Here is the same thing for a dataclass (class C); here you CAN at least see
the whole of each docstring, but they are on one line together and it's not
all that great, and bits of the Annotated objects appear in this help
output at least 5 times by my count (maybe this can't be helped since it's
part of the Annotated object):

In [4]: from dataclasses import dataclass

In [5]: @dataclass
   ...: class C:
   ...: """Docstring for the C class."""
   ...:
   ...: a: Annotated[int, "here is what i'd call a medium length
docstring"]
   ...: b: Annotated[str, "short docstring"]
   ...:

In [6]: help(C)
Help on class C in module __main__:

class C(builtins.object)
 |  C(a: typing.Annotated[int, "here is what i'd call a medium length
docstring"], b: typing.Annotated[str, 'short docstring']) -> None
 |
 |  Docstring for the C class.
 |
 |  Methods defined here:
 |
 |  __eq__(self, other)
 |
 |  __init__(self, a: typing.Annotated[int, "here is what i'd call a medium
length docstring"], b: typing.Annotated[str, 'short docstring']) -> None
 |
 |  __repr__(self)
 |
 |  --
 |  Data descriptors defined here:
 |
 |  __dict__
 |  dictionary for instance variables (if defined)
 |
 |  __weakref__
 |  list of weak references to the object (if defined)
 |
 |  --
 |  Data and other attributes defined here:
 |
 |  __annotations__ = {'a': typing.Annotated[int, "here is what i'd call
a...
 |
 |  __dataclass_fields__ = {'a':
Field(name='a',type=typing.Annotated[int,...
 |
 |  __dataclass_params__ =
_DataclassParams(init=True,repr=True,eq=True,or...
 |
 |  __hash__ = None

Here is the ipython ? output for the dataclass, by the way-- it is FAR
better! But this is only so nice because dataclasses adds the typing
information to the __init__ signature. For regular classes (like class B
above), we would not get this nice output when using ?.

In [7]: C?
Init signature:
C(
a: typing.Annotated[int, "here is what i'd call a medium length
docstring"],
b: typing.Annotated[str, 'short docstring'],
) -> None
Docstring:  Docstring for the C class.

[Python-ideas] Re: Runtime-accessible attribute docstrings – take 2

[Ricky Teachey]

On Wed, Dec 8, 2021 at 1:20 PM Paul Bryan  wrote:

> I believe a Annotated[..., str] could become an attribute docstring if by
> consensus we deem it to be so. I can't see any disadvantages, perhaps save
> for the verbosity of `Annotated`. It certainly seems like an advantage to
> use an existing mechanism rather than define a new one that would appear to
> require changes to the interpreter.
>

I think this would be better than nothing. But it is a little verbose. And
it requires you to supply the type hint.

I use type hinting, but I don't want to use it every time I provide an
Annotation/docstring.

Maybe we could do both: establish the 2nd argument of Annotated as the
docstring (and adjust the output of help() and other tools accordingly),
but also provide a new "shortcut syntax" as Steven proposed:

E_s : float : "the elastic modulus of steel"

... is sugar for:

E_s : typing.Annotated[float, "the elastic modulus of steel"]

...and:

x :: "spam"

...is sugar for:

x : typing.Annotated[typing.Any, "spam"]

---
Ricky.

"I've never met a Kentucky man who wasn't either thinking about going home
or actually going home." - Happy Chandler
___
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/KTJ6BTJJJTGS42JLQWMATDLWXGWPZHZT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Runtime-accessible attribute docstrings – take 2

[Ricky Teachey]

On Wed, Dec 8, 2021 at 12:46 PM Paul Bryan  wrote:

> I propose there is already a viable option in typing.Annotated. Example:
>
> @dataclass
>
> class InventoryItem:
>
> """Class for keeping track of an item in inventory."""
>
> name: Annotated[str, "Short name of the item."]
>
> unit_price: Annotated[float, "Price per unit in dollar."]
>
> ...
>
>
> I've been using this in production code for about a year (with code that
> generates OpenAPI document), with additional validation constraints, and
> it's proving to be quite usable.
>
> Paul
>

As I noted in the previous thread, a big downside IMO of using Annotated
for docstrings is it really makes the help() output quite messy. The
"docstrings" appear in at least 5 different places (as part of the
Annotation objects).

This could be fixed, I guess. But that would skip over a question that gets
raised here, which is: are a docstring and an annotation really the same
thing? Are there disadvantages to assuming they are?

---
Ricky.

"I've never met a Kentucky man who wasn't either thinking about going home
or actually going home." - Happy Chandler


>
___
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/JUGZ6UJHQQCCQNH7MCGMGJG6WZD4QAQJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Runtime-accessible attribute docstrings – take 2

[Ricky Teachey]

On Wed, Dec 8, 2021 at 8:41 AM Steven D'Aprano  wrote:

> On Wed, Dec 08, 2021 at 11:50:55AM -, tmkehrenb...@gmail.com wrote:
> > A few weeks ago, I proposed on this mailing list to write docstrings for
> > class attributes like this:
> >
> > @dataclass
> > class A:
> > x: int
> > """Docstring for x."""
> >
> > The main criticism, I think, was that it is weird to have the docstring
> > *below* the attribute.
>
> ...
>
> Rather than implicitly linking a bare string to the following (or
> previous?) attribute, this would explicitly link them by putting them on
> the same line (at least for short docstrings).
>
> Full declaration syntax becomes:
>
> name : Type = value : docstring_expression
>
> with the various parts being optional. Example:
>
>
> @dataclass
> class InventoryItem:
> """Class for keeping track of an item in inventory."""
>
> name: str : "Short name of the item"
> unit_price: float : "Price per unit in dollar."
> quantity_on_hand: int = 0 : (
> "Available quantity currently in the warehouse.")
>
>
> The docstring expression could evaluate to any value, not necessarily a
> string, but conventionally one would use a string, and I expect style
> guides would discourage or ban non-strings. (But see below for a
> possible objection.)
>
> Aside from the name, each part of the syntax is optional:
>
> # Type hint only.
> name: Type
>
> # Assignment only.
> name = value
>
> # Declare a type hint, and a docstring.
> name: Type : docstring
>
> # Assign a value, and a docstring, with no type hint.
> name = value : docstring
>
> # And all three: type hint, value and docstring.
> name: Type = value : docstring
>
>
> If this makes sense, one might even have an attribute with no type hint
> or value, only a docstring:
>
> name : : docstring
>
> which would assign the docstring to `__attrdoc__` but otherwise have no
> effect.
>
> ...
>
>
> --
> Steve
>

IMO this is a much better idea than the OP's, or the similar d-string idea
I had come up with.

Here's an example of the kind of thing I imagine doing with this feature.

If I were doing a set of engineering calculations, I might get started by
writing pseudocode (but using the new docstrings) like this:

 cantilevered_beam.py #

"""Checking cantilevered beam designs."""

# material properties
E_s : float : "elastic modulus of steel"
F_y: float : "strength of steel"

# beam properties
I_beam : float : "moment of inertia of beam"
S_beam : float : "section modulus of beam"
L_beam : float : "cantilever length"
phi_M : float : "moment limit of beam"

# loads
P_u : float : "applied ultimate force"
M_u : float : "applied ultimate bending moment"

# deflections
delta_max : float : "maximum beam deflection"
delta_limit : float : "beam deflection limit"

check : bool : "Is the beam OK? - OK (true) or No Good (false)"

### end of module 

This code doesn't yet do anything, but there is a ton of information being
shared here- information that can be used to write code later, quickly. It
is a very nice module template that could be used over and over again
(writing out the details of actual projects later).

Of course you could write pseudocode containing all of this information
today with regular strings. But the difference is that, if this were to be
a language feature, the information is going to be available
programmatically BEFORE actually implementing anything at all.

If I were in a jupyter notebook, I could write something like this (you
could so similar things a REPL):

[CELL 1]
import cantilevered_beam
print("\n".join(f"{name}:\t{docstring}" for name,  docstring in
cantilevered_beam.__attrdoc__.items()))

...and it would nicely output all the documentation written in the template
module above for my reference, and in the next cell I would interactively
compose code like this (probably copying and pasting from above, and then
typing over the type-hints and docstrings):

[CELL 2]
 my_cantilevered_beam.py #
"""A check for a cantilevered beam design."""

# material properties
E_s = 29_000  # ksi
F_y = 50  # ksi

# beam properties
I_beam = 1_830  # in^4 for W 24x68 beam
S_beam = 154  # in^3 for W 24x68 beam
L_beam = 190.25  # inches
phi_M = 0.9 * F_y * S_beam  # kip-in

P_u = 4.947  # kips
M_u = P_u *  L_beam  # kip-in
delta_max = P_u * L_beam**3 / (48 * E_s * I_beam)  # inches
delta_limit = 1  # inches
check = True if M_u <= phi_M and delta_max <= delta_limit else False

Could I accomplish something similar today using regular strings? Sure. But
it seems to me that having an official way to document attributes/members
has been an oft requested feature, and I really like imaging the kinds of
things I would be inclined to do with it if it were supported in the
language (rather than something I was off doing on my own as a
low-experience programmer, and wondering if it was dumb or a mistake).

---
Ricky.

"I've never met a Kentucky man who 

[Python-ideas] Re: Runtime-accessible attribute docstrings – take 2

[Ricky Teachey]

I think it's an interesting idea. I made the same or at least similar
suggestion in the previous thread, but it didn't receive any responses. I
assume this is because people weren't very interested (but I also
understand people are busy).

Here's that message:

https://mail.python.org/archives/list/python-ideas@python.org/message/SJEPCZOLSRZSVQENIKOVWVCJXTF4Z2WT/

---
Ricky.

"I've never met a Kentucky man who wasn't either thinking about going home
or actually going home." - Happy Chandler


On Wed, Dec 8, 2021 at 6:56 AM  wrote:

> A few weeks ago, I proposed on this mailing list to write docstrings for
> class attributes like this:
>
> @dataclass
> class A:
> x: int
> """Docstring for x."""
>
> The main criticism, I think, was that it is weird to have the docstring
> *below* the attribute.
>
> To solve this problem, I propose to introduce a new kind of string: a
> d-string ('d' for 'docstring'; alternatively also 'v' because it looks a
> bit like a downward arrow, or 'a' for 'attribute docstring'). A d-string
> is a normal string, except that it is stored in __attrdoc__ when used
> inside a class. It is stored with the name of the variable *below*
> it as the key.
>
> Examples:
>
> @dataclass
> class InventoryItem:
> """Class for keeping track of an item in inventory."""
>
> d"""Short name of the item."""
> name: str
> d"""Price per unit in dollar."""
> unit_price: float
> d"""Available quantity currently in the warehouse."""
> quantity_on_hand: int = 0
>
>
> InventoryItem.__attrdoc__ == {
> "name": "Short name of the item.",
> "unit_price": "Price per unit in dollar.",
> "quantity_on_hand": "Available quantity currently in the warehouse.",
> }
>
> 
>
> class HttpRequest(Enum):
> """Types of HTTP requests."""
>
> d"""GET requests are used to retrieve data."""
> GET = auto()
> d"""POST requests are used to insert/update remote data."""
> POST = auto()
>
>
> HttpRequest.__attrdoc__ == {
> "GET": "GET requests are used to retrieve data.",
> "POST": "POST requests are used to insert/update remote data.",
> }
>
> d-strings can be combined with raw strings by using the prefix rd or dr.
> d-strings could also be used to document module-level constants:
>
> # in my_module.py:
> d"Number of days in a week."
> DAYS_PER_WEEK: Final = 7
>
>
> my_module.__attrdoc__ == {"DAYS_PER_WEEK": "Number of days in a week."}
>
> -Thomas
> ___
> 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/VV5MOSIRVSTRDTA5NFVVUXGD2JFBERRS/
> 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/R6XERPYJTYCLA7ONR4NP72KJZLLX7ARQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Runtime-accessible attribute docstrings

[Ricky Teachey]

This might be a weird idea but I think it looks nice, is backward
compatible, and flexible.

It could be a convention to have the type hint syntax location (ie, the
syntax location after the colon that usually contains type hints only
today) do double duty. It could be used for documentation as long as it is
provided FIRST.

Then, optionally provide the type hint information on a later line:

@dataclass
class A:
"""Docstring for class A."""

   x: "Docstring for x"
x: int

   y: "Docstring for y"
y: bool = True

In this way one could provide the docstrings in all together in a separate
section of code, as long as the docstrings came before the final type hint
and any default values:

@dataclass
class A:
"""Docstring for class A."""

   x: "Docstring for x"
   y: "Docstring for y"

x: int
y: bool = True

People that have no interest in type hinting their code and don't intend
for it to run through a type checker can use the same convention without
any issues:

class A:
"""Docstring for class A."""

   x: "Docstring for x"
   y: "Docstring for y"


If desired and if it became a popular idea, language support could later be
provided to make use of these docstrings- saving them in a useful place-
and bring them into help() output in a proper looking way.

I am unsure if this would be backwards compatible with mypy.

__

WARNING: half baked idea ahead! ahoy there be dragons here probably, etc etc
___

Expanding on that idea: if language support for making use of this
documentation convention is indeed later wanted but it were deemed too
problematic, and potentially backwards incompatible, to differentiate
docstrings from regular typing information, there could be a docstring
literal d"", similar to f string literal:

@dataclass
class A:
"""Docstring for class A."""

   x: d"Docstring for x"
   y: d"Docstring for y"

x: int
y: bool = True

To be clear there is nothing magical about the d"" string itself. It's just
a regular string. The d"" moniker merely causes the string contents to be
stored away for safe keeping in a class or module dunder, storing all the
info for the created docstrings in a dictionary:

>>> print(A.__member_docstrings__)
{'x': 'Docstring for x', 'y': 'Docstring for y'}

Using only convention, you could do all sorts of fancy shenanigans with
these docstrings.

You could provide format fields in the docstring such as using a
convention for identifying the variable name on the LHS inside the
docstring, or its type hint (type hint maybe defaulting to Any if there
isn't a type hint?):

class A:
"""Docstring for class A."""

   x: d"{var} is of type {hint}"
   y: d"{var} is of type {hint}"

Documentation tools line help() could know about __member_docstrings__ and
these conventions, properly parse them using the format() method:

>>> help(A.x)
x is of type Any

In this way the help function or other documentation tools wouldn't require
type hint information, and a type hint could even be defined/changed later
(such as in a child class).

class B(A):
"""Docstring for class B."""

   x: int

>>> help(A.x)
x is of type int

I'm unsure how the help() function, or other similar documentation tools,
could know where to look (ie, in the parent class) for the docstring
information. Seems like this could be solved in some way, though.

On Fri, Nov 19, 2021, 6:23 PM Angelo Kontaxis 
wrote:

> I feel like we could possible use the slots being a dict here, this is
> already a supported feature and is able to document attributes indivually,
> and dataclasses does have a slots argument now in 3.10
>
> class Foo:
> """docstring for Foo"""
> __slots__ = {"bar": "docstring for bar"}
> def __init__(self, bar):
> self.bar = bar
> ___
> 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/DC5JBXCFDE3B3FQ2MZVKCQG4ODWSXG32/
> 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/SJEPCZOLSRZSVQENIKOVWVCJXTF4Z2WT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Runtime-accessible attribute docstrings

[Ricky Teachey]

On Thu, Nov 18, 2021 at 1:39 PM Thomas Grainger  wrote:

> Ricky Teachey wrote:
> > Could this be a use case for typing.Annotated?
> > In [6]: from dataclasses import dataclass
> > In [7]: from typing import Annotated
> > In [8]: class A:
> >...: """Docstring for class A."""
> >...: x: Annotated[int, "Docstring for x"]
> >...: y: Annotated[bool, "Docstring for y"] = True
> > In [9]: A.__annotations__
> > Out[9]:
> > {'x': typing.Annotated[int, 'Docstring for x'],
> >  'y': typing.Annotated[bool, 'Docstring for y']}
> > The syntax is a bit arduous; I'd be in favor of thinking through ways to
> > make it easier to write. But the basic functionality already exists;
> > there's no reason to duplicate it with another language feature.
> > Rick.
> > ---
> > Ricky.
> > "I've never met a Kentucky man who wasn't either thinking about going
> home
> > or actually going home." - Happy Chandler
> > On Thu, Nov 18, 2021 at 5:50 AM tmkehrenb...@gmail.com wrote:
> > > Stephen J. Turnbull wrote:
> > > @standard_class_docstring_parser
> > > class A:
> > > """
> > > Class docstring.
> > > x:  Docstring for x
> > > y:  Docstring for y
> > > """
> > > x: int
> > > y: bool = True
> > > Oh, this is actually a nice idea. You could have a
> > > decorator that parses reST and then according
> > > to some conventions extracts the attribute
> > > docstrings. I think I will try to write something like
> > > that.
> > > Thomas
> > > ___
> > > 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/F2QJ3Q.
> ..
> > > Code of Conduct: http://python.org/psf/codeofconduct/
> > >
>
> I think you need to use another type rather than a plain string here eg:
>
>
> ```
> @dataclasses.dataclass(frozen=True)
> class Doc:
> v: str
>
> @dataclasses.dataclass
> class A:
> """docstring for class A."""
> x: typing.Annotated[int, Doc("docstring for x")]
> ```
>

I don't know why you would? It seems to work just fine with a plain string?

One thing that is bad about it: the class member "docstrings" (actually the
annotations) are repeated all over the place (look like 4 times total?) in
the help() output-- example is below:

>>> help(A)
Help on class A in module __main__:

class A(builtins.object)
 |  A(x: *typing.Annotated[int, 'docstring for x']*) -> None
 |
 |  docstring for class A.
 |
 |  Methods defined here:
 |
 |  __eq__(self, other)
 |
 |  __init__(self, x: *typing.Annotated[int, 'docstring for x']*) -> None
 |
 |  __repr__(self)
 |
 |  --
 |  Data descriptors defined here:
 |
 |  __dict__
 |  dictionary for instance variables (if defined)
 |
 |  __weakref__
 |  list of weak references to the object (if defined)
 |
 |  --
 |  Data and other attributes defined here:
 |
 |  __annotations__ = {'x': *typing.Annotated[int, 'docstring for x']*}
 |
 |  __dataclass_fields__ = {'x': Field(name='x',type=
*typing.Annotated[int,..*.
 |
 |  __dataclass_params__ =
_DataclassParams(init=True,repr=True,eq=True,or...
 |
 |  __hash__ = None

---
Ricky.

"I've never met a Kentucky man who wasn't either thinking about going home
or actually going home." - Happy Chandler
___
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/BXCEE4G6SDYWI4LQMTPZ3AWAJN2I3EMD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Runtime-accessible attribute docstrings

[Ricky Teachey]

On Thu, Nov 18, 2021 at 10:28 AM Ricky Teachey  wrote:

> Could this be a use case for typing.Annotated?
>
> ...
>
> The syntax is a bit arduous; I'd be in favor of thinking through ways to
> make it easier to write. But the basic functionality already exists;
> there's no reason to duplicate it with another language feature.
>
> Rick.
>

Whoops sorry, forgot the @dataclass decoration:

In [10]: @dataclass
...: class A:
...: """Docstring for class A."""
...: x: Annotated[int, "Docstring for x"]
...: y: Annotated[bool, "Docstring for y"] = True
...:

---
Ricky.

"I've never met a Kentucky man who wasn't either thinking about going home
or actually going home." - Happy Chandler
___
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/3RQNYZ2IG7QOORECD2DXO7BQ27AROCGX/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Runtime-accessible attribute docstrings

[Ricky Teachey]

Could this be a use case for typing.Annotated?

In [6]: from dataclasses import dataclass

In [7]: from typing import Annotated

In [8]: class A:
   ...: """Docstring for class A."""
   ...: x: Annotated[int, "Docstring for x"]
   ...: y: Annotated[bool, "Docstring for y"] = True

In [9]: A.__annotations__
Out[9]:
{'x': typing.Annotated[int, 'Docstring for x'],
 'y': typing.Annotated[bool, 'Docstring for y']}

The syntax is a bit arduous; I'd be in favor of thinking through ways to
make it easier to write. But the basic functionality already exists;
there's no reason to duplicate it with another language feature.

Rick.

---
Ricky.

"I've never met a Kentucky man who wasn't either thinking about going home
or actually going home." - Happy Chandler


On Thu, Nov 18, 2021 at 5:50 AM  wrote:

> Stephen J. Turnbull wrote:
> > @standard_class_docstring_parser
> > class A:
> > """
> > Class docstring.
> > x:  Docstring for x
> > y:  Docstring for y
> > """
> > x: int
> > y: bool = True
>
> Oh, this is actually a nice idea. You could have a
> decorator that parses reST and then according
> to some conventions extracts the attribute
> docstrings. I think I will try to write something like
> that.
>
> Thomas
> ___
> 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/F2QJ3Q3HFX5VR7MG37FXET5JJ2XVNKSF/
> 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/GXPHAXUXQ3UGWK6YZFSNVSWYGL22INDM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Adding pep8-casing-compliant aliases for the entire stdlib

[Ricky Teachey]

On Thu, Nov 11, 2021 at 9:33 PM Ethan Furman  wrote:

> I think what Paul is referring to is that according to PEP 8:
>
> - functions: Function names should be lowercase, with words separated by
> underscores as necessary
>to improve readability.
>
> - types: Class names should normally use the CapWords convention.
>
> And, of course:
>
> - Names that are visible to the user as public parts of the API should
> follow conventions that
>reflect usage rather than implementation.
>
>
> So, given those three items, should `str` be `str` because it is used
> often as a function, or should it be `Str` because
> it is often subclassed?
>
> --
> ~Ethan~


I understand why this idea got shut down faster than centrifuge-launched
satellite, but I enjoyed reading the resulting thread and I learned a lot.
Especially this idea which I have previously missed:

- Names that are visible to the user as public parts of the API should
follow conventions that
   reflect usage rather than implementation.

Is there a standard idiom-- perhaps using a type-hint-- to signal to the
IDE/linter that my user-defined class is intended to be used as a
function/factory, and not as a type (even though it is in fact a type)?

Unaware of the "reflected usage" guidelines, I have done this in the past:

class _Spam:
...  # todo

def spam(*args):
return _Spam(*args)

I haven't done this often; usually it hasn't made much sense to bury the
implementation into a private class like this. Most often it has been
because I don't want to commit a class interface as the long term API; want
to leave room to change my mind later.

Seems like if there were a standard idiom for telling the linter "this
class is really just kind of a factory, don't complain about the
lowercase", it might be kind of nice.

---
Ricky.

"I've never met a Kentucky man who wasn't either thinking about going home
or actually going home." - Happy Chandler
___
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/2POVEQWMHPWYVPXOYU4LN3P26ON5DBNA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP 671: Syntax for late-bound function argument defaults -- choice of -> vs @

[Ricky Teachey]

On Wed, Nov 3, 2021, 2:40 PM MRAB  wrote:

> On 2021-11-03 18:14, Ethan Furman wrote:
> > On 11/3/21 10:35 AM, Steven D'Aprano wrote:
> >
> >   > I suppose that we could even add yet another overloaded meaning on
> the
> >   > asterix:
> >   >
> >   >  # with no default, * keeps the old meaning of collecting
> >   >  # extra positional values
> >   >
> >   >  *parameter
> >   >
> >   >  # with a default, * triggers late-binding
> >   >
> >   >  *parameter=expression
> >   >
> >   > I should hate that, I know I should... but I kinda don't.
> >
> > Don't worry, I do.  ;-)
> >
> How about:
>
>  parameter=*expression
>
> so, for example:
>
>  parameter=*[]
>
> indicates that you get a new list for each default, so multiple lists,
> not a single shared list?
>

I'm sure I could get used to it, but that looks to me like you're unpacking
an empty list and assigning the resulting tuple. It's weird.
___
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/5IQURP77KMIZOCNU7PDNFOKAHGJCZ7LP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Beginners accidentally shadow module names due to different expectation of the resolution order for module imports

[Ricky Teachey]

On Wed, Nov 3, 2021, 5:41 PM Chris Angelico  wrote:

On Thu, Nov 4, 2021 at 6:37 AM Ethan Furman  wrote:
>
> On 11/3/21 12:21 PM, Florian Wetschoreck wrote:
>
>  > In order to prevent confusion, I want to point out that the primary
scenario that I meant is not that the file imports
>  > itself but another file in the same directory with the name of a
module that is also installed in site-packages. Not
>  > sure if I made that clear in my original post?
>
> Maybe if the module-level AttributeError included the complete
path/filename of the module?  It would then be much more
> easily discernible that the imported "pandas" is not the correct one.
>

I like this idea. It already happens with a from-import. A cursory
look at Objects/moduleobject.c suggests that it'd be one more lookup
in the error handling in module_getattro, pretty doable.

ChrisA



Why not go one step further and let the user know there is/was another
pandas waiting in line to be imported "maybe you intended to import
module of the same name at these other locations".

This would be an expensive disk read if you did it at the time the
exception was raised, but what if at import time python kept a reference
around to the other candidate locations of a module name that would have
been imported? Most of the time those locations would not have changed.

And furthermore to reduce any hit to performance you could have it only
site this information for this helpful error message if the import came
from the local directory and not somewhere like site packages. Though I
don't know how people would feel about different error messages bubbling up
depending on where a module was imported from
___
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/3GBMOZXIETUTQAJBZ7QHPDJJYKRN4ANH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Print and eval

[Ricky Teachey]

Are you familiar with the f-string self-documentation operator in python
3.8?

https://docs.python.org/3/whatsnew/3.8.html#f-strings-support-for-self-documenting-expressions-and-debugging

With it you can say:

print(f"{a==b=}")


---
Ricky.

"I've never met a Kentucky man who wasn't either thinking about going home
or actually going home." - Happy Chandler


On Mon, Nov 1, 2021 at 10:31 PM Evan Greenup via Python-ideas <
python-ideas@python.org> wrote:

> It would be nice to add the following syntax sugar in Python "Print and
> Eval"
>
> like `ptev a == b` It is same as `statement = "a == b";
> print(f"{statement} ? {eval(statement)}")`.
>
> It would super nice for debugging and other research project.
>
>
> ___
> 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/NQ6NZIALIVNNVMYZSSFF7Y2Q4W736O7L/
> 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/A4P2HXIT2C5EY5DPW65XBTCYHYZB4XBY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP 671: Syntax for late-bound function argument defaults

[Ricky Teachey]

On Tue, Oct 26, 2021 at 10:44 PM Chris Angelico  wrote:

> On Wed, Oct 27, 2021 at 1:13 PM Ricky Teachey  wrote:
> >
> > I'll try to summarize why I still have pause even though after thinking
> about it I still can't really think of a solid example showing that this
> "give me the default" issue is a concrete problem:
> >
> > Until this point, exactly how to provide a default argument value has
> been the Wild West in python, and as Paul Moore said, there's really not a
> way to introspect whether a parameter was "defaulted". The result is that a
> cornucopia of APIs have flourished. By necessity, all these previous APIs
> provided ways to ask for the default through passing some special value,
> and this has felt like "the pythonic way"for a night time. We are all used
> to it (but perhaps only tolerated it in many cases).
> >
> > The proposal blesses a new API with language support, and it will
> suddenly become THE pythonic approach. But this newly blessed, pythonic API
> is a radical departure from years- decades- of coding habits.
> >
>
> That's a very good point, but I'd like to turn it on its head and
> explain the situation from the opposite perspective.
>
> For years - decades - Python has lacked a way to express the concept
> that a default argument is something more than a simple value. Coders
> have used a variety of workarounds. In the future, most or all of
> those workarounds will no longer be necessary, and we will have a
> single obvious way to do things.
>
> Suppose that, up until today, Python had not had support for big
> integers - that the only numbers representable were those that fit
> inside a 32-bit (for compatibility, of course) two's complement
> integer. People who need to work with larger numbers would use a
> variety of tricks: storing digits in strings and performing arithmetic
> manually, or using a tuple of integers to represent a larger number,
> or using floats and accepting a loss of precision. Then Python gains
> native support for big integers. Yes, it would be a radical departure
> from years of workarounds. Yes, some people would continue to use the
> other methods, because there would be enough differences to warrant
> it. And yes, there would be backward-incompatible API changes as edge
> cases get cleaned up. Is it worth it? For integers, I can respond with
> a resounding YES, because we have plenty of evidence that they are
> immensely valuable! With default argument expressions, it's less of an
> obvious must-have, but I do believe that the benefits outweigh the
> costs.
>
> Will the standard library immediately remove all "=None" workaround
> defaults? No. Probably some of them, but not all. Will there be
> breakage as a result of something passing None where it wanted the
> default? Probably - if not in the stdlib, then I am sure it'll happen
> in third-party code. Will future code be more readable as a result?
> Absolutely.
>
> ChrisA
>

If I might paraphrase Agrippa from the book of Acts: "Almost thou
persuadest me..." ;) It's a fine answer.
  <http://python.org/psf/codeofconduct/>
Thanks for the attentiveness to my concern, Chris. Very much appreciated!

---
Ricky.

"I've never met a Kentucky man who wasn't either thinking about going home
or actually going home." - Happy Chandler
___
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/UCQSCITR6RWUNLFZ73WAFCC2X3HCQO7M/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP 671: Syntax for late-bound function argument defaults

[Ricky Teachey]

On Tue, Oct 26, 2021, 9:54 PM Rob Cliffe via Python-ideas <
python-ideas@python.org> wrote:

>
>
> On 27/10/2021 01:47, Chris Angelico wrote:
> > The idea that a
> > parameter is optional, but doesn't have a value, may itself be worth
> > exploring (maybe some way to say "arg=pass" and then have an operator
> > "if unset arg:" that returns True if it's unbound), but that's for
> > another day.
> >
> > ChrisA
> Indeed.  And it could be useful to know if a parameter was passed a
> value or given the default value.
> Python has very comprehensive introspection abilities, but this is a
> (small) gap.
> Rob Cliffe
>

I'll try to summarize why I still have pause even though after thinking
about it I still can't really think of a solid example showing that this
"give me the default" issue is a concrete problem:

Until this point, exactly how to provide a default argument value has been
the Wild West in python, and as Paul Moore said, there's really not a way
to introspect whether a parameter was "defaulted". The result is that a
cornucopia of APIs have flourished. By necessity, all these previous APIs
provided ways to ask for the default through passing some special value,
and this has felt like "the pythonic way"for a night time. We are all used
to it (but perhaps only tolerated it in many cases).

The proposal blesses a new API with language support, and it will suddenly
become THE pythonic approach. But this newly blessed, pythonic API is a
radical departure from years- decades- of coding habits.

And so even though I like the proposal, I'm just concerned it could be a
little bit more painful than at first glance. So it just seems like some
version of these concerns belongs in the PEP.

Thanks Chris A for putting up with what isn't much more than a hunch (at
least on my part) and I'll say nothing more about it. Carry on.

>
___
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/OSJKSROAWNBHXRCI33V3HK6OEXV2IRA3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP 671: Syntax for late-bound function argument defaults

[Ricky Teachey]

On Tue, Oct 26, 2021 at 2:40 PM Chris Angelico  wrote:

> On Wed, Oct 27, 2021 at 5:30 AM Ricky Teachey  wrote:
> > But with function k below, where the b parameter is deferred, you can't
> get the default b parameter by dynamically unpacking some values; you would
> have to pass c as a kwd arg:
> >
> > def k(a, b=>len(a), c=None):
> > ...
> >
> > Seems like it would be- needed? convenient?- to be able to "ask" for the
> default in a dynamic way... Am I making more of this than is justified?
> >
>
> Question: Does it make sense to ask for the default for the second
> positional parameter, while passing an actual value for the third? If
> it does, then the function needs an API that reflects this. The most
> obvious such API is what you already described: passing c as a
> keyword argument instead. I don't think this is a problem. When you're
> looking at positional args, it is only ever the last N that can be
> omitted. If it makes sense to pass any combination of arguments, then
> they should probably be keyword-only, to clarify this.
>
> Do you have any examples where this isn't the case?
>
> ChrisA
>

I don't. I only have a niggling feeling that maybe this is a bigger problem
than we're giving it credit for.

If I can, I'll try to substantiate it better. Maybe others can better flesh
out the concern here if it's valid.

At bottom I guess I'd describe the problem this way: with most APIs, there
is a way to PASS SOMETHING that says "give me the default". With this
proposed API, we don't have that; the only want to say "give me the
default" is to NOT pass something.

I don't KNOW if that's a problem, it just feels like one.

---
Ricky.

"I've never met a Kentucky man who wasn't either thinking about going home
or actually going home." - Happy Chandler
___
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/57JDHXLKZGK6G6WYVAQDN46XWW35ORYG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP 671: Syntax for late-bound function argument defaults

[Ricky Teachey]

On Tue, Oct 26, 2021 at 2:05 PM Paul Moore  wrote:

> On Tue, 26 Oct 2021 at 16:48, Eric V. Smith  wrote:
> >
> > And also the "No Loss of Abilities If Removed" section sort of applies
> > to late-bound function arguments: there's nothing proposed that can't
> > currently be done in existing Python. I'll grant you that they might
> > (might!) be more newbie-friendly, but I think the bar is high for
> > proposals that make existing things doable in a different way, as
> > opposed to proposals that add new expressiveness to the language.
>
> One issue with not having an introspection capability, which has been
> bothering me but I've not yet had the time to come up with a complete
> example, is the fact that with this new feature, you have functions
> where there's no way to express "just use the default" without knowing
> what the default actually *is*.
>
> Take for example
>
> def f(a, b=None):
> if b is None:
> b = len(a)
> ...
>
> def g(a, b=>len(a)):
> ...
>
> Suppose you want to call f as follows:
>
> args = [
> ([1,2,3], 2),
> ([4,5,6], None),
> ([7,8,9], 4),
> ]
>
> for a, b in args:
> f(a, b)
>
> That works fine. But you cannot replace f by g, because None doesn't
> mean "use the default", and in fact by design there's *nothing* that
> means "use the default" other than "know what the default is and
> supply it explicitly". So if you want to do something similar with g
> (allowing the use of None in the list of tuples to mean "use the
> default"), you need to be able to introspect g to know what the
> default is. You may also need to manipulate first-class "deferred
> expression" objects as well, just to have something you can return as
> the default value (you could return a string and require the user to
> eval it, I guess, but that doesn't seem particularly user-friendly...)
>
> I don't have a good solution for this, unfortunately. And maybe it's
> something where a "good enough" solution would be sufficient. But
> definitely, it should be discussed in the PEP so what's being proposed
> is clear.
>
> Paul
>

I had drafted an entire reply last night trying to explain this same
concern;  Paul Moore, you did a better job. Just want to say I agree: being
able to say "I want the defaults" seems like a useful ability.

But on the other hand, we also must recognize that right now there isn't
really a great, UNIVERSAL way to say "I want the defaults". It varies from
API to API. Many times getting the default means passing None, but many it
is True, or False, or a MISSING sentinel. You have to read the docs to find
out.

Taking PM's examples of f and g, the way you'd have to dynamically call g
this way be:

for arg_group in args:
g(*arg_group)

But this is going to be limiting because maybe you could also have a
function j, like this:

def j(a, b=None, c=None):
if b is None:
b = len(a)
...


args = [
([1,2,3], 2, "spam"),
([4,5,6], None, "eggs"),
([7,8,9], 4, "bacon"),
]

for a, b, c in args:
j(a, b, c)

But with function k below, where the b parameter is deferred, you can't get
the default b parameter by dynamically unpacking some values; you would
have to pass c as a kwd arg:

def k(a, b=>len(a), c=None):
...

Seems like it would be- needed? convenient?- to be able to "ask" for the
default in a dynamic way... Am I making more of this than is justified?

---
Ricky.

"I've never met a Kentucky man who wasn't either thinking about going home
or actually going home." - Happy Chandler
___
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/E6JHPA3KBO6RXLUBVRHJGVMYQFKQEBBZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP 671: Syntax for late-bound function argument defaults

[Ricky Teachey]

On Mon, Oct 25, 2021 at 3:42 PM Mike Miller 
wrote:

>
> On 2021-10-25 11:27, Ethan Furman wrote:
> > - `deferred` soft keyword
>
>
> "defer" please.
>
> This construct did not happen in the past, and it's shorter of course.
>
> -Mike
>

For soft keyword options, defer is better than deferred.

But previously I suggested ellipses (because to me it looks kind of like
"later..."). Chris A didn't care for it, but and I still kind of like it
despite his objections:

def f(a, b = ... []):
...

Chris A said it could be a problem because ellipses are legal in an
expression, but I don't think that should be a problem for the PEG parser?
This would be syntactically legal, though not very useful:

def f(a, b = ... ...): ...

...and this would be syntactically legal, but would result in an error:

def f(a, b = ... ...+1): ...

If everyone hates the ... bikeshed color, my other suggestion would be
"late" (standing for "late binding"), which is 1 character shorter than
"defer", and semantically meaningful:

def f(a, b = late []): ...

---
Ricky.

"I've never met a Kentucky man who wasn't either thinking about going home
or actually going home." - Happy Chandler
___
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/HG6RDHZHUCOSZW65T6PKM35554IA2AAG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Syntax for late-bound arguments

[Ricky Teachey]

It seems to me that the syntax for late binding could be chosen so as to
leave the possibility of expansion open in the future, and defer (har har)
the entire generalized thunk discussion?

So why not go with syntax like this, where before the ? just represents a
keyword to be bike shedded ("defer", "thunk", "later", ""):

def func(a, b=? a): ...

I kind of like using the ellipses btw; it looks sort of like "later..." to
me:

def func(a, b = ... a):
...
___
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/3F2I2N3OO2M34XYOR4SKCA2KQ4FFJBOK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Syntax for late-bound arguments

[Ricky Teachey]

This might be a dumb question but is the context built only left to right?
Or will this be legal?

def f(a, *, b=:c, c=:b):
print(f"{a=} {b=} {c=}")

>>> f(1, b=2)
a=1 b=2 c=2

>>> f(1, c=2)
a=1 b=2 c=2
___
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/CXF5DEE7UBR63ZCAXJKWI4E3ALQM3X2U/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Implementing string unary operators

[Ricky Teachey]

I'm here all week. Tip your wait staff.

Also, genuine apologies if mine was perceived as mean-sarcastic. It was
definitely sarcastic but I hoped it was fun enough in tone not to seem
mean-spirited. I apologize sincerely and without reservation and I would do
it better next time. :)

On Tue, Oct 19, 2021, 8:35 PM Steven D'Aprano  wrote:

> On Wed, Oct 20, 2021 at 11:10:52AM +1100, Chris Angelico wrote:
> > On Wed, Oct 20, 2021 at 11:02 AM Steven D'Aprano 
> wrote:
> > > Ironically, Ricky's in-fun suggestion that we use the tilde operator
> for
> > > swapcase was the only suggestion in these two threads that actually met
> > > the invariant for an inverse that ~~x == x.
> > >
> >
> > >>> x = "ß"
> >
> > :) Okay, so it's *mostly* an invariant.
>
> Hah, well spotted!
>
> Ironically, there is an uppercase eszett, 'ẞ', although font support for
> it may still be limited. (Come on font designers, it has only been
> official in Unicode since 2008 and in German orthography in 2017).
>
> --
> Steve
> ___
> 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/BSSSU5FWJDGWIJBCWQK7VMVAG5O2SJ7Q/
> 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/5XYGJNATVNV2VCUE66ODQL5OY7PBDVYX/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Real Positional Arguments or OO Currying

[Ricky Teachey]

On Mon, Oct 18, 2021 at 2:13 PM Matt del Valle  wrote:

> 
> Ricky's curry helper decorator is cool, but for me the drawback that makes
> it a dealbreaker is that it is too dynamic for IDE's to understand. I write
> a lot of library code and find myself routinely foregoing metaprogramming
> and runtime attribute/function/class generation in favor of statically
> declared code so that my consumers will receive assistance from their
> editors.
>

I'll go further: the IDE would be rendered nearly useless! And this is
probably the biggest single drawback-- if part of the motivation behind
such a fluent style is to help programmers understand the code they are
writing more quickly as they write it (seems to me to be the goal anyway),
if you also break all the help provided by the IDE in the process, you
haven't attained that coal no matter how nifty your cool new fluent code
style is.

---
Ricky.

"I've never met a Kentucky man who wasn't either thinking about going home
or actually going home." - Happy Chandler
___
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/YW7KPJPUFUCHTXZ2TJGY65K6JDLKXBPI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Real Positional Arguments or OO Currying

[Ricky Teachey]

Yeah if you change the API to be a bit more powerful, you could build all
kinds of ideas on top of the basic kernel of idea...

Here's some others I was shooting around with a python-eque buddy of mine
this morning:

@curry_helper
def is_(x):
...  # elsewhere

@is_.add_predicate
def a_number(x):
return isinstance(x, float)

@is_.add_predicate
def an_instance_of(x, y):
return isinstance(x, y)

Then you can say:

is_(x).a_number()
is_(x).an_instance_of(y)

Or you could also do:

@curry_helper
def insert(arg):
...  # elsewhere

@insert.add_predicate
def into(obj, cls):
if not isinstance(obj, cls):
raise TypeError(f"{type(obj).__qualname__}")

@insert.into.add_predicate(obj='m', cls=MutableMapping)
def mapping(k, v, m):
if k in m:
raise KeyError(f"{k!r} already exists")
m[k] = v

@insert.add_predicate(obj='s', cls=MutableSequence)
def seq(x, s):
...  # elsewhere

@insert.seq.add_predicate(x='x', s='s')
def at(x, s, i):
s.insert(i, x)

The idea there would be to provide a way to pass arguments to parent
functions, and then:

insert(x).into.seq(s).at(i)
insert(k, v).into.mapping(m)

I would never use any of this in a serious application, but it's still fun.

---
Ricky.

"I've never met a Kentucky man who wasn't either thinking about going home
or actually going home." - Happy Chandler


On Mon, Oct 18, 2021 at 12:27 PM Mathew Elman 
wrote:

> This is interesting, it's not as nice as native syntax support could have
> been but a decorator like this is also pretty nice.
> I think I would bikeshed this so the decorator was the full dot separated
> signature, e.g.
>
> @curry_helper('insert.into')
> def insert(x: Any, y: list):
> def y.append(x)
>
> but other than that, I think this is probably the closest thing I'll get
> out of this, so thanks.
> ___
> 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/NBMWJ54XSI6JQESR7ZXUR4WFYW7GNHU4/
> 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/QLV5JWB6HKI22FY6ZFIHZ2S7MVCJYP5P/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Real Positional Arguments or OO Currying

[Ricky Teachey]

I kind of like this idea. I wrote this curry helper module as a proof of
concept of how to implement it in Python, today, without having to add
features:

https://gist.github.com/Ricyteach/b290849da903135a1ed5cce9b161b8c9

Using that, you can write code like this:

from typing import Any

@curry_helper(suffixes=["into"])
def insert(x: Any, y: list):
y.append(x)

item = 1
container = []
insert(item).into(container)
assert container == [item]

@curry_helper(suffixes=["an_instance_of_"])
def is_(obj, cls):
return isinstance(obj, cls)

obj = 1
assert is_(obj).an_instance_of_(int)


the API could be adjusted in all sorts of ways, but I don't think the need
to apply a decorator with a list of suffixes like this is too bad.

---
Ricky.

"I've never met a Kentucky man who wasn't either thinking about going home
or actually going home." - Happy Chandler
___
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/NLY454T3S6UFD7KPO57NUAA2WEV22B3J/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Accessing target name at runtime

[Ricky Teachey]

On Fri, Oct 15, 2021 at 6:02 PM Jeremiah Paige  wrote:

>
>
> 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
>

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
___
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/I6ZF7MJGN44WNPE2JY5ZPHJQHRIGEPOI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Structure Pattern for annotation

[Ricky Teachey]

On Fri, Oct 15, 2021 at 1:06 PM Finn Mason  wrote:

> I love the proposal for dicts, but I agree that this discourages duck
> typing. Could the curly braces notation represent Mapping, not dict
> specifically?
>
> +1 to shortening tuples but not other sequences.
>
>
> --
> Finn Mason
>


That might be useful. But don't forget there is also MutableMapping.

---
Ricky.

"I've never met a Kentucky man who wasn't either thinking about going home
or actually going home." - Happy Chandler
___
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/ICTEPGREJLEVCKYMQ6MYLKRCNZ7NO7SY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Structure Pattern for annotation

[Ricky Teachey]

On Thu, Oct 14, 2021 at 8:46 AM Paul Moore  wrote:

>
> ...maybe the energy focused on "making basic types easier to write"
> should be focused on making protocols easier to write, instead.
>
> Paul
>

+ a billion

Rick.

---
Ricky.

"I've never met a Kentucky man who wasn't either thinking about going home
or actually going home." - Happy Chandler
___
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/FAKH72P57D3BZEH2BVUA5H27V63E5NCO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Structure Pattern for annotation

[Ricky Teachey]

I think all of this additional syntax is just a mistake.

The reason is it will encourage people to not properly annotate their input
types for duck typing. Some of these shortcuts might be nice for output
types. But the more general trying.Mapping, typing.Sequence and friends
should be preferred for input types. If terse shortcuts are available for
the concrete data structure types, but not for the generic types, a lot of
people are going to feel nudged to type hint their python improperly.

On Thu, Oct 14, 2021, 4:54 AM Alex Waygood  wrote:

> I agree with Steven. I very much like Abdulla's proposed syntax for
> dicts, TypedDicts and sets. But I'm not sure that the idea for `Annotated` is
> workable, and the proposal for lists seems too prone to ambiguity, given
> how extensively square brackets are already used in typing syntax.
>
> One question about the proposals, however: how would we represent other
> mappings apart from dicts? Would `collections.abc.Mapping` and `
> types.MappingProxyType` still be spelled as `Mapping[str, int]` and 
> `MappingProxyType[str,
> int]`? If so, that would be a slightly annoying inconsistency.
>
> I *do *also quite like the idea of an improved syntax for *tuples 
> *specifically.
> Tuples are already very different types to lists/strings/etc in the context
> of typing, essentially representing heterogeneous structs of fixed length
> rather than homogenous sequences of unspecified length. As such, I think it
> "makes sense" to special-case tuples without special-casing other sequences
> such as list, `collections.abc.Sequence` or `collections.deque`.
>
> def foo() -> tuple[list[list[str]], list[list[str]]]
>
> would become
>
> def foo() -> (list[list[str]], list[list[str]])
>
> That feels quite readable and natural, to me.
>
> Best,
> Alex
>
> On 14 Oct 2021, at 09:25, Steven D'Aprano  wrote:
>
> On Thu, Oct 14, 2021 at 12:32:57AM +0400, Abdulla Al Kathiri wrote:
>
> Today I found myself write a function that returns a tuple of list of
>
> list of strings (tuple[list[list[str]], list[list[str]]]). Wouldn’t it
>
> easier to read to write it like the following:
>
> ([[str]], [[str]])?
>
>
> Not really. Your first example is explicit and I can get the meaning by
> just reading it out loud:
>
>tuple[list[list[str]], list[list[str]]]
>
>"tuple (of) list (of) list (of) str, list (of) list (of) str
>
> Your abbreviated version:
>
>([[str]], [[str]])
>
> is too terse. I have to stop and think about what it means, not just
> read it out loud. Without the hint of named types (tuple and list), my
> first reaction to seeing [str] is "is this an optional string?".
>
> And then I wonder why it's not written:
>
>([[""]], [[""]])
>
> Why abbreviate list and tuple but not string?
>
> Code is read more than it is written, and can be too terse as well as
> too verbose.
>
> On the other hand:
>
> Similarly for TypedDict, replace the following..
>
> class Movie(TypedDict):
>
>name: str
>
>year: int
>
> with
>
> {‘name’: str, ‘year’: int}
>
>
> To my eye, that one does work. As far as I know, curly brackets {}
> aren't otherwise used in annotations (unlike square brackets), and they
> don't look like "optional" to me. They look like a dict.
>
> So on first glance at least, I think that:
>
>{'name': str, 'year': int}
>
> is better than the class syntax we already have.
>
>
> Likewise:
>
> dict[str, int] will be {str: int}
>
> set[int] will be {int}.
>
>
> work for me too.
>
>
> Also, Annotated[float, “seconds”] can be replaced with something like
>
> float #seconds indicating whatever comes after the hashtag is just
>
> extra information similar to a normal comment in the code.
>
>
> No, because the # indicates that the rest of the line is a comment. This
> is already legal:
>
>def func(d: {str  # this is an actual comment
> : int}) -> Any: ...
>
> so this would be ambiguous between a real comment and an annotation.
>
> Even if we agreed to change the behaviour of comments, you suggested:
>
>func(d: {str # product label: [float] # prices from 2000 to 2015})
>
> How is the interpreter to know that the first annotation is just
>
>"product label"
>
> rather than this?
>
>"product label: [float] # prices from 2000 to 2015"
>
> So I don't think this works.
>
>
> --
> Steve
> ___
> 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/T7E54DZW6EENRT373ZMCTU5WWRQ5M2TN/
> 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 arc

[Python-ideas] Re: Implementing additional string operators

[Ricky Teachey]

On Wed, Oct 13, 2021, 11:01 AM Stephen J. Turnbull <
stephenjturnb...@gmail.com> wrote:

Chris Angelico writes:

 > +1, although it's debatable whether it should be remove suffix or
 > remove all. I'd be happy with either.

If by "remove all" you mean "efefef" - "ef" == "", I think that's a
footgun.  Similarly for "efabcd" - "ef" == "abcdef" - "ef".

Steve


Maybe it should be "remove the first one" rather than a suffix.

Then for removal of multiple substrings, you could allow the RHS to be a
sequence of substrings:

>>> "efaxefef" - "ef"
"axefef"
>>> "efaxefef" - ["ef", "ax"]
"efef"
>>> "efaxefef" - ["ef"]*3
"ax"

BTW these are interesting ideas and I'm just exploring the possibilities.
Not proposing or agreeing with anything.
___
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/E3OWMUU7C2P2WT53PYWDMVWNKHCZR7WF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Overloading unary plus in strings with "ord"

[Ricky Teachey]

On Tue, Oct 12, 2021 at 9:40 AM MRAB  wrote:

> On 2021-10-12 13:49, Steven D'Aprano wrote:
> > On Tue, Oct 12, 2021 at 11:36:42PM +1100, Chris Angelico wrote:
> >
> >> You haven't given any reason why unary plus should imply ord().
> >
> > I think the question Chris is really asking is why should unary plus
> > return ord() rather than any other function or method.
> >
> > We could make unary plus of a string equal to the upper() method:
> >
> >  +"Hello world"  # returns "HELLO WORLD"
> >
> You could then strengthen that suggestion by saying the unary minus
> would be equivalent to the lower() method.
>

I would "strengthen" it further by suggesting swapcase for the squiggle
operator:

>>> ~"Lime Cordial Delicious"
'lIME cORDIAL dELICIOUS'

And title case for the carot:

>>> ^"lime cordial delicious"
'Lime Cordial Delicious'

So many shortcuts! Think of the line space savings.

---
Ricky.

"I've never met a Kentucky man who wasn't either thinking about going home
or actually going home." - Happy Chandler
___
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/3AAALBGEWZJ3QQC6OJQGC2TRVMISPNMT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: dict_items.__getitem__?

[Ricky Teachey]

On Wed, Oct 6, 2021 at 10:55 AM Finn Mason  wrote:

> I'm not a huge fan. Sure, dicts are ordered now, but I doubt that many
> people use that feature. I honestly still think of them as unordered ;)
>

I've seen several people say this so I'll be a voice on the other side: I
am not a pro developer so my practices should probably not  be weighted all
that much. But nevertheless, I have been constantly relying on order-ness
in regular dicts ever since it was non-official thing in cpython. I
actually did a little happy dance in my chair when RH announced this at
pycon years ago.

I am sure I am not the only one.

---
Ricky.

"I've never met a Kentucky man who wasn't either thinking about going home
or actually going home." - Happy Chandler
___
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/IMFYPRJAX2LJ5G6UERNADUZENHGP4FXI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Reusing more builtins for type-hinting

[Ricky Teachey]

On Sat, Oct 2, 2021, 10:40 AM Ricky Teachey  wrote:

> Just spitballing but how about any.obj as an alias for typing.Any? It
> suffers from the same problem as using naked any- which is that any doesn't
> really have anything to do with type hinting... but it doesn't suffer from
> the problem of having to convert any to a type. It would just grow a class
> attribute referring to typing.any. And it seems pretty readable to me.
>
> Rick.
>

Sorry I should have said function attribute, not class attribute. Hopefully
it was clear.

>
___
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/MB4WIP4REAPCKFMQTADEEY2GBQ7DFCNS/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Reusing more builtins for type-hinting

[Ricky Teachey]

Just spitballing but how about any.obj as an alias for typing.Any? It
suffers from the same problem as using naked any- which is that any doesn't
really have anything to do with type hinting... but it doesn't suffer from
the problem of having to convert any to a type. It would just grow a class
attribute referring to typing.any. And it seems pretty readable to me.

Rick.

On Sat, Oct 2, 2021, 10:30 AM Serhiy Storchaka  wrote:

> 02.10.21 17:10, Todd пише:
> > Is there a reason we can't use "Object" and make "Any" just an alias for
> > "Object"?
>
> If you mean "object", then the reason is that "object" has no methods
> and attributes (besides few dunder methods like __repr__ and
> __reduce__), while "Any" has all methods and attributes.
>
> ___
> 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/NMKXERTCY3ROGUNKMKPIMRMAZWSPOFCO/
> 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/LQYA57TE5IQTTOIIGXTAWXEAMQXTGDMY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Reusing more builtins for type-hinting

[Ricky Teachey]

On Fri, Oct 1, 2021 at 2:52 PM Christopher Barker 
wrote:

> On Fri, Oct 1, 2021 at 8:05 AM Paul Moore  wrote:
>
>> Having to take the runtime cost of an import to do a development-time
>> static analysis of the code, sort of is, though...
>
>
> Perhaps so — though I’d think that could be addressed in a more
> comprehensive way. Thus can’t be the only runtime overhead that could
> conceivably be avoided.
>
> And if that was the primary goal, add Any to builtins…
>
> -CHB
>
>
>>
>> Paul
>
>
on the one hand: with all the other type-hint syntax made available (gone
are the need for importing Optional, Union, Type, Dict, List, Tuple, and
Set) and more coming, having to import Any certainly does feel annoying.

it seems to me, in my own code at least, that many others in the typing
module are used just as often (if not more!) than Any: TypeVar, Generic,
and ClassVar to name a few.

there are also the collections.abc types. input argument hints are more
robust and proper when using types like : Mapping[] and Sequence[] (and
their Mutable friends) rather than using Dict[] and List[] and Tuple[]
(which can now be dict[] and list[] and tuple[]). so these are in constant
use for function argument type-hints. so if Any is going to matriculate its
way into built-ins, i don't see much of a reason why a big chunk of the
rest of the typing module shouldn't.

that being the case, i think it should probably stay where it is.

---
Ricky.

"I've never met a Kentucky man who wasn't either thinking about going home
or actually going home." - Happy Chandler
___
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/XO33WHAD3JYXF4A6BXX5AK2UKTWEKN2G/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Reusing more builtins for type-hinting

[Ricky Teachey]

On Fri, Oct 1, 2021 at 9:49 AM Matt del Valle  wrote:

> I had no idea that type[Something] was already a thing, and this makes me
> so happy! :)
>
> It's true that `any` would have to converted to be either:
>
> 1) an object implementing __call__ and __getitem__
> 2) a type implementing __new__ and __class_getitem__
> 3) some special-cased type implemented in the interpreter that couldn't be
> recreated in python (like maybe implementing `any` as a special subclass of
> `builtin_function_or_method` that can be subscripted or allowing
> `builtin_function_or_method` to be optionally subscriptable)
> 4) some other option I'm not thinking of?
>
> The first two options would *technically* represent a
> backwards-incompatible change, but it's hard to imagine any **sane** code
> that would be affected. You'd have to be doing something like:
>
> ```
> import builtins
>
> builtin_function_or_method = type(max)
>
> for item in builtins.__dict__.values():
> if isinstance(item, builtin_function_or_method):
> ...  # do something with all the builtin functions, which would no
> longer include `any`
> ```
>
> The third option would neatly sidestep this and be fully
> backwards-compatible, but I assume would represent a bigger change to the
> interpreter.
>
> As I don't have any knowledge of the interpreter's internals I can't
> really give a preference for an approach, but I think the first step would
> be agreeing that a subscriptable version of `any` for type-hinting is
> desirable.
>
> If this seems to be something that people want then I'm sure there are
> people far more qualified than me to discuss implementation details. If not
> then it's irrelevant anyway.
>
>
I'd expect to see something more like an EAFP construct;

try:
maybe_all_maybe_mapping[key]
except KeyError:
# it's all()!

I agree it would be weird. But not hard to imagine.

---
Ricky.

"I've never met a Kentucky man who wasn't either thinking about going home
or actually going home." - Happy Chandler
___
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/GJZFK3VBIXFYAGYJSQVPFMRRGOK7B3NK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Reusing more builtins for type-hinting

[Ricky Teachey]

On Fri, Oct 1, 2021 at 8:02 AM Matt del Valle  wrote:

> In the spirit of 3.9 allowing builtin collections like `list`, `dict`,
> `tuple`, and `set` to be subscripted for type-hinting to remove the need
> for importing their equivalents from `typing`, I'd like to propose the same
> thing for a few other builtin objects, namely:
>
> `type` (for use instead of`typing.Type`)
> `any` (for use  instead of `typing.Any`)
> `callable` (for use instead of `typing.Callable`)
>
> (I'm aware that a better syntax for type-hinting callables using
> arrow-syntax is potentially currently in the works, so maybe this last one
> can be ignored)
>
> Having to explicitly import objects from `typing` for basic type-hinting
> use-cases is a not-inconsiderable source of frustration preventing their
> uptake, especially by beginners. 3.9 made a valuable step forward in
> reducing this friction, but I think we can go further.
>

 As was already stated: type[Thing] is already in the works, and callable
is also being addressed elsewhere. This leaves any().

But any() is a function and not a type; it would have to graduate to a type
for the type-hint syntax to work. Seems like that could cause some
problems. Additionally, all() is in many ways the cousin of any(), and
all() would presumably remain a function. I wonder if this asymmetry would
also cause problems?

Have you thought about any of this?

---
Ricky.

"I've never met a Kentucky man who wasn't either thinking about going home
or actually going home." - Happy Chandler
___
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/SFR23A2OCQKAKTIDUGOMMRPMAMNJO66Z/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Shorthand syntax for lambda functions that have a single parameter

[Ricky Teachey]

Will we be able to splat/unpack the `?`?

>>> args = get_starting_list_values()
>>> args
(1, 2, 3)
>>> dd = defaultdict([*?])
>>> dd["spam"]
[1, 2, 3]

or:

>>> kwargs = get_kwargs()
>>> kwargs
{'x': 1, 'y' 2, 'z': 3}
>>> dd = defaultdict(Node(**?))
>>> dd["eggs"]
Node(x=1, y=2, z=3)

---
Ricky.

"I've never met a Kentucky man who wasn't either thinking about going home
or actually going home." - Happy Chandler


On Wed, Sep 29, 2021 at 9:03 AM Chris Angelico  wrote:

> On Wed, Sep 29, 2021 at 10:56 PM Dominik Vilsmeier
>  wrote:
> > members.sort(key=(?[1], ?[0]))
>
> How do you know whether this is one function that returns a tuple, or
> a tuple of two functions?
>
> 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/LFSBND3PDEM7XFZD3E73MILTDTT4HPQJ/
> 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/NKUDQMUBOT43SPBQ6LN3G47WN5PBXSMG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP Draft: Power Assertion

[Ricky Teachey]

My first thought was: it would be very nice, when doing quick and dirty
scratch code, to not have to resort to a full fledged test framework to get
readable assertions. You could just throw an assert statement in a if
__name__ == '__main__' block at the bottom, click the run arrow next to it
in pycharm or other IDE, and get more readable assertion errors.

It doesn't seem like it is recreating pytest; pytest is far more than
rewritten assertions (though it's a key feature of course).

On the other hand, providing an API for hooking into the assert mechanism
could be more useful. Imagine pytest spinning out their assertion rewriting
functionality into a separate project that you could turn into a plugin in
VS Code or Pycharm. And it would be much more easily extendable.

+1 on the basic idea/desire for rewritten assertions appearing in more
places than pytest. +1 on official support for hooking into the assertion
machinery and letting a thousand flowers bloom. +0 on the actual proposed
PEP.

On Sat, Sep 25, 2021, 5:50 AM Paul Moore  wrote:

> On Sat, 25 Sept 2021 at 06:09, Stephen J. Turnbull
>  wrote:
> >
> > Guido van Rossum writes:
> >
> >  > I think this is by far the best option. Pytest can evolve much faster
> than
> >  > the stdlib.
> >
> > Is there no room for making it easier to do this with less invasive
> > changes to the stdlib, or are Steven d'A's "heroic measures in an
> > import hook" the right way to go?
>
> +1 on this. There are a number of "better exceptions" packages out
> there (for example, `better_exceptions` :-)) which would benefit from
> an improved mechanism to introspect failed assertions. A language
> change to make life easier for all those packages seems like an
> "obvious" feature to me.From there, it's a relatively small step to
> having a better *default* assertion reporting mechanism, but the PEP
> should focus on the machinery first, and the front end second IMO.
>
> Paul
> ___
> 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/J3SQIJ4USRQ3XSUVOSUR5C6NKA3GLQZ4/
> 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/EKJ6U3KDDSVURLX4ZPT4XN5TOL2JFHDI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Otherwise clause in for statement to run when a empty iterable is used

[Ricky Teachey]

On Sun, Sep 19, 2021, 6:42 PM Andre Delfino  wrote:

> Your code has an unpacking error in the first line. I think you mean this,
> right?
>
> no_items = object()
> item = no_items
>
> for item in get_items():
> frob(item)
>
> if item is no_items:
> raise ValueError()
>

Sorry yes. Actually I intended to write this but it's the same thing.

no_items = item = object()

>
___
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/ZDEPZSKX4CHOB637TKQDSMEQ4RUPR4BH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Otherwise clause in for statement to run when a empty iterable is used

[Ricky Teachey]

On Tue, Sep 14, 2021 at 11:02 PM Valentin Berlier 
wrote:

> I find that when I run into a similar scenario the reason why I need the
> iterable to be non-empty is because I'm trying to find something in it, and
> for this the `else` clause works pretty well:
>
> for item in get_items():
> if check(item):
> do_thing(item)
> break
> else:
> raise ValueError()
>
> Early returns can also be useful:
>
> for item in get_items():
> if check(item):
> return do_thing(item)
> raise ValueError()
>

Another useful method is a sentinel:

item, no_items = object()

for item in get_items():
frob(item)

if item is no_items:
raise ValueError()

---
Ricky.

"I've never met a Kentucky man who wasn't either thinking about going home
or actually going home." - Happy Chandler
___
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/JLE7PBAJJYNWSDSMV2DMIUQ5QQ6FDPMA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Addition of a "plus-minus" binary numeric operator

[Ricky Teachey]

May I ask what you are actually doing with upper and lower after creating
them? Are you checking to see if another value is between? Something else?
If they are always being used together and you're doing the same things
with them all the time, it starts to smell like you might want to just
write a class.

---
Ricky.

"I've never met a Kentucky man who wasn't either thinking about going home
or actually going home." - Happy Chandler


On Tue, Sep 14, 2021 at 10:11 AM Ir. Robert Vanden Eynde <
robertv...@gmail.com> wrote:

> Add you can call this function plusminus
> Then use the funcoperators module to write :
>
> upper, lower = a +plusminus- b
>
> pip install funcoperators
>
> Le mar. 14 sept. 2021 à 16:02, Paul Moore  a écrit :
>
>> I doubt it, it seems way too specialised to be worth making into a
>> language feature.
>>
>> If you want to, you can write a function:
>>
>> def limits(a, b):
>> return a+b, a-b
>>
>> Paul
>>
>> On Tue, 14 Sept 2021 at 14:55,  wrote:
>> >
>> > Hi all,
>> >
>> > I was wondering on whether there is any interest in introducing a
>> "plus-minus" operator:
>> >
>> > Conceptually very simple; instead of:
>> >
>> > upper, lower = a + b, a - b
>> >
>> > use instead:
>> >
>> > upper, lower = a +- b
>> >
>> > In recent projects I've been working on, I've been having to do the
>> above "plus minus" a lot, and so it would simplify/clean-up/reduce error
>> potential cases where I'm writing the results explicitly.
>> >
>> > It isn't a big thing, but seems like a clean solution, that also takes
>> advantage of python's inherent ability to return and assign tuples.
>> > ___
>> > 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/MCAS5B63Q6ND74GEBP2N3OF3HLISSQMA/
>> > 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/XYRRZPCPWF6VJTBX3MAWCIQEWXJC5F3X/
>> 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/527MLDIJ3EHBPGSS2KJ4CBP3RVMR4JBZ/
> 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/PNMWXFP6ETVT425CGOZQW4UPEKAZ6TR6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Different exceptions for assert

[Ricky Teachey]

On Thu, Sep 9, 2021 at 12:38 PM Christopher Barker 
wrote:

> Take a look at the archives of this list -- there was a large
> conversation about DBC a while back (a year, two years ??? )
>
> I think if you really want to support DBC, there will need to be more
> changes than this -- though there are libraries that support it with
> current Python.
>
> Also, let's be clear about hte language re use -- when you say:
>
> there should be lots of assertions, do you mean the english were
> assertion, or the Python keyword assert?
>
> If the former, than you are free, or course, to use a ordinary if and
> raise to make all sort sof assertions about the code at runtime.
>
> To me -- the entire point of the assert statement is that it is for
> testing, and can be turned off. If you want to check a condition always,
> just use an if and a raise:
>
> How is this:
>
> if value < 0:
> raise ValueError("this only works with positive numbers")
>
> Any more difficult to read or write than:
>
> assert value >= 0, raise ValueError("this only works with
> positive numbers")
>
> -CHB
>

I have never heard of DBC and don't have a clue what is stands for. I am
not a pro software developer.

But I would read these two lines differently, semantically. The if version
feels like someone is saying "I am checking for a thing that could happen".
The assert version would feel more like "maybe this could happen and I am
checking for it because I am scared not to let's just put it here just in
case", or said another way "it is imperative that this not happen".

Not sure if that is an argument for or against, and maybe I'm the only one
who would see the semantics differently.


---
Ricky.

"I've never met a Kentucky man who wasn't either thinking about going home
or actually going home." - Happy Chandler
___
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/JZ75CBXCY4XCUXECWV3P666HPZEJ3YOK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP8 mandatory-is rule

[Ricky Teachey]

On Wed, Sep 1, 2021 at 1:32 PM Nick Parlante  wrote:

> In fairness to Nick, he is not talking about the real world. Nick is
>> talking about the hot-house environment of *education*, where fragile
>> newbies are generally protected from real world issues.
>
>
> Let me unpack this just a teeny bit. We don't need to think of the
> students as fragile. Think of it as where the minutes go.
>
> Like why is Java worse? You are trying to explain about comparisons, and
> you need like 30 minutes for Java where the number of different required
> comparison facilities is big, and it just looks needlessly complicated.
> What is the problem with that? Think of it this way: I wanted to talk about
> *algorithms* and solving real problems .. like those are the best uses of
> lecture time and examples. If the language injects something that you feel
> is not such a great use of time, you notice that those minutes are taken
> away from the actual course goals.
>
> Now for Python, == vs. is nothing like that bad. Both == and is are
> sensible, necessary parts of the language, I would just prefer to talk
> about == earlier and is later. Of the two, == is the no-brainer one when
> the students just have ints and strings, and no-brainer is what you want in
> week 2.
>
> For teaching, you are not just identifying the 500 important things they
> need to know. To teach artfully, you are trying to think of an ordering,
> layering on 50 new things each week, where the subest achieved each week is
> internally coherent and you can do a project just using that subset, and at
> the end of the course you've gotten through everything.
>
> Best,
>
> Nick
>

A couple people have said this but I'll ask again because I am curious:
would it be possible to delay introduction of None entirely until it's time
to introduce is?

The biggest thing None seems to be needed for beginners is to learn the
idiom for function signature default arguments for mutable parameters (the
classic "Least Astonishment" and the Mutable Default Argument problem

).

If the goal of the course is to get as quickly as possible to  *algorithms*
and solving real problems, then I don't see why you even need to teach
default arguments at all.

---
Ricky.

"I've never met a Kentucky man who wasn't either thinking about going home
or actually going home." - Happy Chandler
___
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/57JNYNRHEEUV4NSOYPEZ44K23LFP7V7I/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: NAN handling in statistics functions

[Ricky Teachey]

On Tue, Aug 31, 2021 at 9:17 AM Ricky Teachey  wrote:

> Can someone explain why enum-vs-string is being discussed as if it is an
> either-or choice? Why not just call the enum class using the input so that
> you can supply a string or enum?I understand this would not be a really
> great choice for a flags enum or int enum, but for single-choice strings,
> it seems like a reasonable approach to me.
>
> 
>
> ...in the past, I have used enums like this in my own code mostly as 1. a
> documentation feature so I can easily remember what the valid choices are,
> and 2. an easy error catcher since you get a nice exception when you supply
> an invalid string to the enum class:
>

Whoops, the repl session was incorrect, apologies. Hopefully it was clear
what I meant. Corrected version below.

>> class MyEnum(Enum):
...  a = "a"
...  b = "b"
...
>>> MyEnum("c")
Traceback (most recent call last):
  File "", line 1, in 
  File "c:\program files\python39\lib\enum.py", line 384, in __call__
return cls.__new__(cls, value)
  File "c:\program files\python39\lib\enum.py", line 702, in __new__
raise ve_exc
ValueError: 'c' is not a valid MyEnum


---
Ricky.

"I've never met a Kentucky man who wasn't either thinking about going home
or actually going home." - Happy Chandler
___
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/AVHR7STJZQQQCPP3JIBSL27FYYNYINXE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: NAN handling in statistics functions

[Ricky Teachey]

Can someone explain why enum-vs-string is being discussed as if it is an
either-or choice? Why not just call the enum class using the input so that
you can supply a string or enum?

NanChoice(nan_choice_input)

I understand this would not be a really great choice for a flags enum or
int enum, but for single-choice strings, it seems like a reasonable
approach to me.

In the example below from my own code I just call the enums using the input
strings so that whether I decide to pass in a string, or import and use an
actual enum object, it will work fine either way.

from enum import Enum
import pandas as pd


class LoadType(Enum):
dead = "D"
live = "L"
snow = "S"
wind = "W"
seismic = "E"
D = "D"
L = "L"
S = "S"
W = "W"
E = "E"


class RiskCategory(Enum):
"""Risk Category of Buildings and Other Structures for Flood,
Wind, Snow, Earthquake, and Ice Loads.

cf. Table 1.5-1
"""
I = "I"
II = "II"
III = "III"
IV = "IV"


_Table_1_pt_5_dsh_2 = pd.DataFrame({LoadType.snow: [0.80, 1.00, 1.10, 1.20],
 LoadType.seismic: [1.00, 1.00, 1.25, 1.50]},
index=list(RiskCategory))


def importance_factor(load_type_input):
return lambda risk_input:
_Table_1_pt_5_dsh_2[LoadType(load_type_input)][RiskCategory(risk_input)]


Maybe this idea sucks? I don't have any way of knowing since nobody reads
my code other than future me (who happens to be somewhat dim), but in the
past, I have used enums like this in my own code mostly as 1. a
documentation feature so I can easily remember what the valid choices are,
and 2. an easy error catcher since you get a nice exception when you supply
an invalid string to the enum class:

>>> class MyEnum(Enum):
...  a: "a"
...  b: "b"
...
>>> MyEnum("c")
Traceback (most recent call last):
  File "", line 1, in 
  File "c:\program files\python39\lib\enum.py", line 384, in __call__
return cls.__new__(cls, value)
  File "c:\program files\python39\lib\enum.py", line 702, in __new__
raise ve_exc
ValueError: 'c' is not a valid MyEnum


Could this approach be useful for handling nans in the stats module? Maybe
the overhead of calling the enum be considered too high or something?


---
Ricky.

"I've never met a Kentucky man who wasn't either thinking about going home
or actually going home." - Happy Chandler
___
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/ZH4CCDFTGZRCO6XBNMM354HOHLPNDUR5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: We should have an explicit concept of emptiness for collections

[Ricky Teachey]

On Mon, Aug 23, 2021 at 12:13 AM David Mertz, Ph.D. 
wrote:

> Everyone in this thread should absolutely read Lewis Caroll's delightful
> and "What the Tortoise Said to Achilles."  It's a very short 3-page story
> that addressed exactly this topic in 1895... even before Guido's Time
> Machine.
>
> One free copy of the public domain work is at:
>
>   https://wmpeople.wm.edu/asset/index/cvance/Carroll
>
>
That he's mad, 'tis true,
'tis true 'tis pity,
And pity 'tis, 'tis true
-- Hamlet, Act 2, Scene 2


---
Ricky.

"I've never met a Kentucky man who wasn't either thinking about going home
or actually going home." - Happy Chandler
___
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/IPJIPFYD62IVIETGAIDVHTI47P3H2RKA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: We should have an explicit concept of emptiness for collections

[Ricky Teachey]

On Sun, Aug 22, 2021, 1:07 PM MRAB  wrote:

> On 2021-08-22 17:36, Thomas Grainger wrote:
> > bool((len(collection) == 0) is True) == True and issubclass(True, bool)
> >
> 'True' is a reserved word, so you don't need to check it.
>
> However, 'bool' might have been overridden, so:
>
> __builtins__.bool((len(collection) == 0) is True) == True
>
> Come to think of it, 'len' might have been overridden too, so:
>
> __builtins__.bool((__builtins__.len(collection) == 0) is True) == True


Bug report: I had to override __builtins__ please fix your code :)

>
___
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/65J7M4VRPF2MNHFY655BD4XTMVCL2QS2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: slices syntactic sugar

[Ricky Teachey]

On Thu, Aug 12, 2021 at 5:16 PM Steven D'Aprano  wrote:

> On Thu, Aug 12, 2021 at 09:57:06AM -0400, Ricky Teachey wrote:
>
> > This got me thinking just now: allowing ellipses instead of None for the
> > first two arguments of the slice() constructor might be a neat idea.
>
> Like this?
>
> >>> obj = slice(..., ..., 5)
> >>> print(obj)
> slice(Ellipsis, Ellipsis, 5)
>
> The arguments to slice can be anything you like.
>
> >>> slice({'a': object()}, int, ('spam', 'eggs'))
> slice({'a': }, , ('spam',
> 'eggs'))
>
> and the interpretation is entirely up to the class:
>
> >>> class C:
> ... def __getitem__(self, obj):
> ... return obj
> ...
> >>> C()["Hello world!":[]:2.5j]
> slice('Hello world!', [], 2.5j)
>
> Aside from the use of a literal `...` for Ellipsis, which is a lot more
> recent, this behaviour goes back to Python 1.5 or older. Slices have
> always been liberal about what they accept.
>
>
> --
> Steve
>

Oh man thanks for pointing that out... and of course numpy and pandas and
many other libraries already use ellipses for various things in slices.

and of course native python sequences already have far better syntactic
sugar than ellipses:

[][3:]
[][::-1]

etc etc.

So given that, why would we ever want to use ellipses?!?!


---
Ricky.

"I've never met a Kentucky man who wasn't either thinking about going home
or actually going home." - Happy Chandler
___
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/DWS4I5KVRY75UTSSFDYVI5J27KAD7NPH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: slices syntactic sugar

[Ricky Teachey]

On Thu, Aug 12, 2021 at 9:02 AM Calvin Spealman  wrote:

> An alternative suggestion, which works today (... is a valid object called
> Ellipsis):
>
>Foobar.search(
> attr1="foo",
> attr2=[10, ...],
> attr3=[42, ..., 50]
> )
>

This got me thinking just now: allowing ellipses instead of None for the
first two arguments of the slice() constructor might be a neat idea.

These looks pretty nice:

slice(1, ...)
slice(1, ...,  2)
slice(-1, ..., -1)
slice(..., ..., 3)

I wonder if-- had the ellipses existed when slice() was created eons ago/in
the depths of time-- whether ... would have been used rather than None for
these.

I'm not really proposing this, just musing.

---
Ricky.

"I've never met a Kentucky man who wasn't either thinking about going home
or actually going home." - Happy Chandler
___
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/G6SEJX5OE2VSVELHGTV4ZOSQNPHWGMPZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Extension methods in Python

[Ricky Teachey]

Would this feature allow me to declare str objects as not iterable in some
contexts?

If so, +1.

On Thu, Jun 24, 2021, 3:22 PM Chris Angelico  wrote:

> On Fri, Jun 25, 2021 at 3:31 AM Steven D'Aprano 
> wrote:
> >
> > Here's a quick and dirty proof of concept I knocked up in about 20
> > minutes, demonstrating that no deep compiler magic is needed. It's just
> > a small change to the way `object.__getattribute__` works.
> >
> > I've emulated it with my own base class, since `object` can't be
> > monkey-patched.
> >
> > The proof of concept is probably buggy and incomplete. It isn't intended
> > to be a final, polished production-ready implementation. It's not
> > implementation-agnostic: it requires the ability to inspect the call
> > stack. If you're using IronPython, this may not work.
> >
> > You will notice I didn't need to touch getattr to have it work, let
> > alone hack the interpreter to make it some sort of magical construct. It
> > all works through `__getattribute__`.
> >
> > The registration system is just the easiest thing that I could throw
> > together. There are surely better designs.
> >
> > Run A.py to see it in action.
> >
>
> Okay, so you've hidden the magic away a bit, but you have to choose
> the number [2] for your stack inspection. That means you have to be
> sure that that's the correct module, in some way. If you do *anything*
> to disrupt the exact depth of the call stack, that breaks.
>
> _hasattr = hasattr
> def hasattr(obj, attr): return _hasattr(obj, attr)
>
> Or any of the other higher level constructs. What if there's a C-level
> function in there?
>
> This is still magic. It's just that the magic has been buried slightly.
>
> 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/RPBIHJE3SHL7S6XIS2343SXCOTW5C54A/
> 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/Z23YL2DJQRUL5KOF6SP5FTW5EOYR3BXD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Deprecate sum of lists

[Ricky Teachey]

On Sat, Jun 19, 2021, 5:00 AM Steven D'Aprano  wrote:

Why are we arguing about `[x,y for y in a]` when nobody has requested
that syntax?


--
Steve


I've wanted many times to be able to write the star unpack there, even as a
relatively modestly experienced python user. But it has never occurred to
me to write this one.
___
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/FGIJE5HY3GQ775EPGHLATPXMLE37PN5P/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Pre PEP: Python Literals (was custom strings before)

[Ricky Teachey]

On Fri, Jun 11, 2021 at 10:12 AM Thomas Güttler 
wrote:

>
>
> Am Fr., 11. Juni 2021 um 14:51 Uhr schrieb Ricky Teachey <
> ri...@teachey.org>:
>
>> I think this idea is promising but instead of doing it by adding new
>> syntax and a totally different object, why not attach a __templates__
>> dunder member to every string but only OPTIONALLY populate it when a string
>> is formatted?
>>
>>
> I am very happy that you think this is promising.
>
> Changing the interface of every string in Python feels much too big for
> me. I don't dare to think about it.
> I have concerns that it could have negative impacts on parts which I am
> not aware of.
>


I'm not a python internals expert, but i am imagining it wouldn't be a very
significant performance hog for anyone not interested in the feature...
seems like all that would be added is the equivalent of a __slot__ to the
str class object, and a reference to None inside it. so the memory
footprint of every string object would not have to grow. the class just
grows a new dunder.

the templated string objects themselves would have to have a bigger memory
footprint of course. but the user/developer is choosing to do that by using
templated strings.

---
Ricky.

"I've never met a Kentucky man who wasn't either thinking about going home
or actually going home." - Happy Chandler
___
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/OKIQ6SQHY7A7SLE4CMPSO7LM66BPUVVI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Pre PEP: Python Literals (was custom strings before)

[Ricky Teachey]

I think this idea is promising but instead of doing it by adding new syntax
and a totally different object, why not attach a __templates__ dunder
member to every string but only OPTIONALLY populate it when a string is
formatted?

For every regular string it would just be None:

 >>> "".__template__
 >>>

But if you create a string using an f string, you can provide a directive,
as part of the format specification mini language, to store it:

 >>> s = f"{foo!t}"

...or a directive at the front of the string to store all the f string
arguments:

 >>> s = ft"{foo}"

This would save the values marked for storage as a tuple of Template
arguments in the __templates__ member for later. It may also be desirable
for the Template object to store the name foo and the position in the
string the foo object was formatted.

So:

 >>> foo = "spam"
 >>> s = f"{foo!t}"

Now instead of being None, s.__template__ would store an object recording
the name foo, what was passed to foo, and the position:

 >>> s.__templates___
(
Template (name="foo", value="spam", position=(0,4)),
)

You could do the same with positional f string arguments, but using an
integer as the name.

An html or log function would later use, or discard, the template
information as it sees fit.


On Fri, Jun 11, 2021, 6:23 AM Thomas Güttler 
wrote:

>
>
> Am Fr., 11. Juni 2021 um 11:10 Uhr schrieb Stephen J. Turnbull <
> turnbull.stephen...@u.tsukuba.ac.jp>:
>
>> Thomas Güttler writes:
>>  > Am Fr., 11. Juni 2021 um 03:17 Uhr schrieb Stephan Hoyer <
>> sho...@gmail.com>:
>>
>>  > > Unevaluated f-strings is a nice way to think about this
>>  > > functionality.
>>
>> But they're not "unevaluated" in a lot of important ways.  A better
>> term might be "pre-assembled". :-)
>>
>>  > > Another use-case that comes to mind is logging. The Google Python
>> style
>>  > > guide says not to use f-strings, for example, because it wants to be
>> able
>>  > > to collect the unexpanded pattern strings and not waste time
>> rendering
>>  > > unlogged messages:
>>  > > https://google.github.io/styleguide/pyguide.html#3101-logging
>>  >
>>  > Thank you Stephan for this feedback. I added Logging to the draft:
>>  > https://github.com/guettli/peps/blob/master/pep-.rst#logging
>>
>> If this does solve the logging problem, it would be a killer app (but
>> that still might not be enough, given that PEP 501 couldn't clear the
>> bar and logging was a leading application for that PEP).  Perhaps you
>> should focus on that rather than the HTML escaping problem.
>>
>>
> Hi Stephen,
>
> I can't solve a problem which I don't know. Logging plays no big role
> in my development tasks any more. I use checks, metrics and sentry.
> In the past logging was important for me, but this changed.
>
> But I am sure that the proposal can be used to improve logging.
>
> Regards,
>   Thomas
>
>
>
> ___
> 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/YEYP2POOB5S5DULJKIQKB3O75RBWUM7Q/
> 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/CG3SJQ5O2NVTHYOIQROHKQ4MLV2G7X5K/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Pre PEP: Python Literals (was custom strings before)

[Ricky Teachey]

On Thu, Jun 10, 2021 at 10:12 AM Stestagg  wrote:

>
> On Thu, Jun 10, 2021 at 2:58 PM Ricky Teachey  wrote:
>
>> Something I don't understand is whether there is anything about this
>> proposed feature that can't be accomplished with a simple function...
>>
>
>
>
>> 
>> And use it like this:
>>
>>  >>>  templify("Here, have some {foo}.")
>>  TemplateLiteral(template = " Here, have some {foo}.", tokens = (("Here,
>> have some ", True), ("spam & eggs", False)))
>>
>>
>> What is it about this task that requires it being handled at the language
>> level...?
>>
>
>  AIUI, that is hard to do without language support, because the function
> templify can't easily access the value of 'foo' because the binding only
> exists in the caller's scope.
>
> So for a simple function to be used, you'd have to pass in the placeholder
> values explicitly as separate arguments, which somewhat defeats the point.
>
> Steve
>
>
Got it now. Should have been able to figure that out on my own thanks for
explaining!

Makes me wonder if stepping back and thinking, instead, about a way to
automatically (optionally?) put the current calling context dictionary(ies)
somewhere that a called function can get at it/them, so it can do what it
wants with the context.

---
Ricky.

"I've never met a Kentucky man who wasn't either thinking about going home
or actually going home." - Happy Chandler
___
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/IM5B7NKEIKPZKWIMTFEZHHBO2XOUOPG5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Pre PEP: Python Literals (was custom strings before)

[Ricky Teachey]

Something I don't understand is whether there is anything about this
proposed feature that can't be accomplished with a simple function.

IIUC, the proposal turns this:

foo = "spam & eggs"
`Here, have some {foo}.`

...into something like this (I am making up a more readable repr):

TemplateLiteral(
template = " Here, have some {foo}.",
tokens = (("Here, have some ", True), ("spam & eggs", False)),
)

What is it about this task that cannot be accomplished with a class and
function? Skeleton might look like:

@dataclass
class TemplateLiteral:
template: str
tokens: Sequence(Tuple(str, bool)) = field(init = False)

def templify(s: str) -> TemplateLiteral:
...

And use it like this:

 >>>  templify("Here, have some {foo}.")
 TemplateLiteral(template = " Here, have some {foo}.", tokens = (("Here,
have some ", True), ("spam & eggs", False)))


What is it about this task that requires it being handled at the language
level...?

---
Ricky.

"I've never met a Kentucky man who wasn't either thinking about going home
or actually going home." - Happy Chandler


On Thu, Jun 10, 2021 at 9:36 AM David Mertz  wrote:

> Strong -1
>
> As others noted in prior discussion, even if this existed, it works be an
> anti-pattern for SQL. So basically, it's just baking in an HTML-only
> template language into the language syntax.
>
> Python already had excellent HTML templating in libraries. The fact Django
> has a function with a long name just suggests importing it with a shorter
> name.
>
> Python has many uses having nothing to do with web pages. This could make
> sense for PHP (does anyone use that still?). It's a poor for for Python.
>
> On Thu, Jun 10, 2021, 2:31 AM Thomas Güttler 
> wrote:
>
>> Thank you Guido, Chris, Matt and Richard for your feedback to my last
>> email.
>>
>> Here is an updated version called "Template Literals".
>>
>> I am looking for a core developer who can sponsor this PEP.
>>
>> Please speak up if you want to help me.
>>
>> Regards,
>>   Thomas Güttler
>>
>> Source and updates: Pre-PEP 
>> 
>>
>> PEP: 
>> Title: Template Literals
>> Author: Thomas Güttler 
>> Sponsor: TODO
>> Status: Draft
>> Type: Standards Track
>> Content-Type: text/x-rst 
>> Created: 08-Jun-2021
>> Python-Version: TODO
>> Post-History: 08-Jun-2021
>> --
>>
>> Contents
>>
>>- Abstract <#m_2818986526677889823_m_-138379983175526697_abstract>
>>- Motivation <#m_2818986526677889823_m_-138379983175526697_motivation>
>>- Rationale <#m_2818986526677889823_m_-138379983175526697_rationale>
>>- Specification
>><#m_2818986526677889823_m_-138379983175526697_specification>
>>- Security Implications
>><#m_2818986526677889823_m_-138379983175526697_security-implications>
>>- Reference Implementation
>><#m_2818986526677889823_m_-138379983175526697_reference-implementation>
>>- Alternative Ideas
>><#m_2818986526677889823_m_-138379983175526697_alternative-ideas>
>>- Rejected Ideas
>><#m_2818986526677889823_m_-138379983175526697_rejected-ideas>
>>- Open Issues
>><#m_2818986526677889823_m_-138379983175526697_open-issues>
>>- References <#m_2818986526677889823_m_-138379983175526697_references>
>>- Copyright <#m_2818986526677889823_m_-138379983175526697_copyright>
>>
>> Abstract <#m_2818986526677889823_m_-138379983175526697_id6>
>>
>> This PEP adds Template Literals to Python.
>>
>> To avoid code injection like XSS or SQL-injection Template Literals can
>> help you to write save Python code.
>>
>> Template Literals provide an easy way to access the local and global
>> variables (like f-strings), so that passing a dictionary to the Template is
>> not necessary.
>> Motivation <#m_2818986526677889823_m_-138379983175526697_id7>
>>
>> In the context of web development Python can do more than providing REST
>> APIs via http. With the trend to Server-Side-Rendering, we face a
>> fundamental question:
>>
>> How to create HTML with Python?
>>
>> If you use the FrOW pattern (HTML fragments over the wire) [1]
>> <#m_2818986526677889823_m_-138379983175526697_frow>, then you will be
>> writing small methods returning small HTML fragments.
>>
>> As a developer I want to pass escaped data into template literals to be
>> as simple as possible.
>> Rationale <#m_2818986526677889823_m_-138379983175526697_id8>
>>
>> Imagine you want to create a small HTML fragment in Python, and return it
>> as HTTP-Response:
>>
>>HttpResponse(f'''
>> Hi {name}
>> Your messages: {messages}''')
>>
>> The problem in above example is, that no escaping gets done.
>>
>> In above example "name" and "messages" should be treated differently.
>>
>> The variable "name" should get escaped. For example if the name is "Mary
>> & Bob", the result should be "Mary & Bob".
>>
>> The variable "messages" contains HTML which is already escaped. It should
>> not be escaped again.
>>
>> Most framework

[Python-ideas] Re: A __decoration_call__ method for Callable objects (WAS: Decorators on variables)

[Ricky Teachey]

Whoops, replying all this time.

On Thu, May 27, 2021 at 2:32 PM micro codery  wrote:

>
>
> On Thu, May 27, 2021 at 10:40 AM Matt del Valle 
> wrote:
>
> I am still very confused as to the scope of this counter proposal re
> variable
> decorating. I have only seen two such examples here
>
> @decorator variable
> # variable = decorator.__decoration_call__(None, "variable")
>
> @decorator variable = "spam"
> # variable = decorator.__decoration_call__(variable, "variable")
>
> But what is actually valid to follow a decorator in this proposal?
> Any simple expression, any expression? Is it limited to assignment
> espressions?
>

At this point, I have in mind any expression that appears to the right,
which I believe is what is allowed today:

@1/2 "lala" and money
def func(): ...


> Here are some interesting uses that were brought up
> in the other thread and I would like to know how they would work.
>
> @decorator
> spam = eggs = cheese = "tomatoes"
>

> @decorator
> spam, eggs, cheese = "tomatoes"
>
> @decorator
> spam, eggs = cheese = "tomatoes"
>
> @decorator
> spam = (eggs := "cheese)
>
> @decorator
> locals()[find_it() or "default"] = spam()
>
>
> Regards,
> ~Jeremiah
>

I would also like to know how all of these work :D I am not sure about most
of them but open to suggestions.

The only one that I feel confident about is:

 @decorator
spam = (eggs := "cheese)

...which, I think, should be:

decorator.__decoration_call__(spam, "spam")

Unfortunately for the proposal most people don't seem too thrilled with it.
So I don't plan to spend a lot of time thinking through these examples and
suggesting behavior. Anyone is welcome to do that though, this isn't MINE
in the sense I am jealously guarding ownership of the details. :)

On Thu, May 27, 2021 at 3:03 PM Brendan Barnwell 
wrote:

> On 2021-05-26 09:43, Ricky Teachey wrote:
> > These two ideas of a decorator syntax result are not the same:
> >
> > RESULT A: function decorator
> > # func = decorator("spam")(func)
> >
> > RESULT B: variable decorator
> > # name = decorator("spam")("name")
> >
> > ...because func is passed as an object, but "name" a string representing
> > the name of the object. Two very different things.
> >
> > For this reason I think I would agree even more so that the differences
> > in the decorator behavior would be an extremely significant point of
> > confusion.
> >
> > This got me to thinking: what if access to the variable name were
> > provided by another means, and ONLY when the decorator syntax is
> employed?
>
> This seems contradictory to me.  It looks like you're saying, "We
> shouldn't use decorator syntax to represent two different things (object
> vs name), but instead decorator syntax should give us access to two
> different things (object vs name)."  I realize based on your proposal
> there is a distinction here but I think it's quite a narrow one and
> doesn't resolve the basic problem, which is that currently decorators
> operate on objects and these new proposals are about making them operate
> on names.
>
> I think there may be value in having some feature that lets us get
> access to the name side of an assignment.  But I wouldn't call such a
> thing a "decorator", nor would I want to use the same @ syntax that is
> used for decorators.  To me that would be confusing, because the
> behavior is totally different.  Even with your __decorator_call__
> proposal, there's still a jarring shift from, in some cases, using just
> the object, and in other cases stuffing a new parameter (the name) into
> the parameter list.  That seems awkward to me.
>
>
> --
> Brendan Barnwell
>

Yes, and for this reason I really liked Steve's googly eyes proposal in the
other thread. But I wonder if there value in specifically giving decorators
access to the name side?

It seems to me that it would open up a lot of possibilities, just as when
descriptors learned their names.

class Desc:
def __set_name__(self, owner, name):
self.name = name
def __get__(self, instance, owner):
if instance is None:
pass
print(f"I am { owner.__name__}.{self.name}")

class C:
v = Desc()

 >>> C().v
 I am C.v

We could make the __decoration_call__ method even more powerful. We could
give it access not just to the name side, but to the type info, and even
the code object/expression side (i.e., RHS).

@decorator
x: Fraction = 1/2
# decorator.__decoration_call__(x, "x&qu

[Python-ideas] Re: A __decoration_call__ method for Callable objects (WAS: Decorators on variables)

[Ricky Teachey]

On Thu, May 27, 2021 at 2:00 PM micro codery  wrote:

> ...
>
By providing the name as the first argument, all
> of my examples of callables currently in the standard library will work as
> you
> say out of the box. If it were to be passed in last, this new syntax would
> not be
> usable by any standard library callable (or even third party? Does anyone
> create factory functions that need the name and take it last?) and lots of
> new
> functions would have to be added.
>
>
> Regards,
> ~Jeremiah
>

Yes that's true.

I originally wrote the proposal with the arguments switched around. But I
it seemed like it could be important to have the decorated_object argument
appear first in the signatures for both __call__ and __decoration_call__,
or it could cause confusion...

However, I am open to the idea I was right the first time.

If so, the default implementation at the top of the object food chain would
be something like (using Matt's SENTINEL idea):

def  __decoration_call__(self, by_name, obj=SENTINEL):
if func is SENTINEL:
return self(by_name)
return self(obj)

On the one hand, this might be too expensive; an identity check and
potentially two function calls occur for all @ decorations. And I don't see
how to optimize this away with opcodes...

On the other hand, how often are people invoking millions of @ decorations
in a loop...?

---
Ricky.

"I've never met a Kentucky man who wasn't either thinking about going home
or actually going home." - Happy Chandler
___
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/O7TW667B7PYBOQ4M52WEXXYNQ6NZN7VM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: A __decoration_call__ method for Callable objects (WAS: Decorators on variables)

[Ricky Teachey]

On Thu, May 27, 2021 at 1:40 PM Matt del Valle  wrote:

> ...



Oh, and I think I've just discovered another thing that I'm not 100% sure I
> like. Even putting aside that I'm not a fan of decorators on the same line
> as the statement they are decorating (as I mentioned in an earlier
> response), you've got examples of variable decorators where no assignment
> is happening such as:
>
> @decorator var
>
> To me this breaks the symmetry between function decorators, which always
> decorate a function definition (an implicit form of assignment), and the
> proposed variable decorators.
>
> They are also confusing in the sense that the decorator is de-facto
> turning an otherwise invalid python statement legal. If you remove the
> decorator from the above example you will presumably get a `NameError`.
>
> I imagine this would then have to be special-cased somehow in the language
> spec so that an undefined name is not evaluated, but only when preceded by
> a decorator? I don't know, it seems messy to me.
>
> Also, I just can't quite see the value in them if I'm honest, whereas the
> version that is applied to an assignment statement:
>
> @decorator var: bool = True
>
> And even a bare type-hint version:
>
> @decorator var: bool
>
> seem to me to be far more self-evidently useful.
>

Ok, agreed on all points. I think an eventual full-fledged proposal could
easily put naked decorations like:

@decorator var

...to the wayside, to be added later if people have a really good reason
for it.

---
Ricky.

"I've never met a Kentucky man who wasn't either thinking about going home
or actually going home." - Happy Chandler
___
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/WYE3N7XCWRCY4HJZ7P644BXAXEUBZL2M/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: A __decoration_call__ method for Callable objects (WAS: Decorators on variables)

[Ricky Teachey]

On Thu, May 27, 2021 at 11:09 AM Matt del Valle 
wrote:

>
>> I'm not the OP, but the way I understand the proposal __decoration_call__
> is only invoked when you actually *use an object to decorate something*.
> That means that a decorator factory will just invoke __call__ as normal,
> because it's nothing but a convenient way to generate a decorator. It is
> not itself a decorator, nor is it used to actually decorate anything. To
> illustrate this point we can separate it out across several lines:
>
> @factory("foo")
> def bar():
> pass
>
>
> Can be rewritten as:
>
> decorator = factory("foo")
>
> @decorator
> def bar():
> pass
>
>
> So __decorator_call__ will only be invoked on the object that gets
> returned from `factory("foo")`, not on `factory`.
>

Correct.


> It seems to me that this proposal means that we can't even tell which of
>> the two protocols (classic decoration, or new `__decoration_call__`
>> style decoration) without digging into the implementation of the
>> decorator.
>>
>> To be precise, the problem here as reader isn't so much the fact that I
>> don't know whether the object is called using the `__call__` protocol or
>> the new-style `__decorator_call__` protocol, but the fact that I can't
>> tell whether the calls will involve the name being passed or not.
>>
>
>
> The OP mentioned a default implementation for __decoration_call__ of:
>
> def  __decoration_call__(self, func, by_name):
> if func is None:
> return self(by_name)
> return self(func)
>
>
> Such that you can assume that the decorator will *always* receive the
> name, but may choose to discard it and not make use of it if it doesn't
> implement the __decoration_call__ interface and instead opts to use default
> implementation which falls back on __call__.
>

Yes but I am on the fence as to whether this default implementation (I
suppose it would live on the object class?) should be considered or not. It
would certainly provide a lot of functionality "out-of-the-box".

For decorated functions the name can always be pulled out of the function
> object as normal even when using __call__, but to make use of the name in a
> decorated assignment statement the decorator would have to override
> __decoration_call__.
>
>
> At this point I will say that I may be putting words into OPs mouth, and
> would be happy to be corrected if I've misunderstood.
>

Nah you got it.


> One final point I've just thought of is that Ricky suggested that when no
> value is assigned to a name that the object reference be `None`. But I
> don't think that works, because it becomes indistinguishable from when
> `None` is explicitly assigned. We would need some sentinel value instead of
> `None` to remove ambiguity in this situation:
>
>
> from somewhere import NOTSET
>
>
> @decorate
> foo: int
>
> def __decoration_call__(self, obj, names, annotation):
> print(obj is None)# False
> print(obj is NOTSET)  # True
>
> @decorate
> foo: int = None
>
>
> def __decoration_call__(self, obj, names, annotation):
> print(obj is None)# True
> print(obj is NOTSET)  # False
>
>
>
Bikesheddable, but I don't know why having these two be equivalent:

@decorator var
@decorator var = None

..would be a problem. Having an implied default of None for var above makes
sense to my brain. Do you have an example in mind where you think it would
create a problem?


---
Ricky.

"I've never met a Kentucky man who wasn't either thinking about going home
or actually going home." - Happy Chandler
___
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/V5PENKCPAGWOFVQKGFGYK666RSD6VLDU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: A __decoration_call__ method for Callable objects (WAS: Decorators on variables)

[Ricky Teachey]

On Thu, May 27, 2021 at 10:25 AM Steven D'Aprano 
wrote:

> On Wed, May 26, 2021 at 12:43:48PM -0400, Ricky Teachey wrote:
>
> [...]
> > These two ideas of a decorator syntax result are not the same:
> >
> > RESULT A: function decorator
> > # func = decorator("spam")(func)
> >
> > RESULT B: variable decorator
> > # name = decorator("spam")("name")
> >
> > ...because func is passed as an object, but "name" a string representing
> > the name of the object. Two very different things.
>
> Ricky, it's not clear to me whether you are proposing the above RESULT A
> and RESULT B as an *alternative* to the "variable decorator" proposal,
> or if you have just misunderstood it.


No, I understood the OP's proposal perfectly. I was agreeing with you
implicitly when you previously said the inconsistency between the OP's
proposal and current decorator is a problem:

:

On the other hand, it would be terribly confusing if the same syntax:
> @decorate
> had radically different meaning depending on whether it was followed by
> a class/function or a bare name


And furthermore, it is even a bigger problem than you explicitly made it
out to be because of passing and object vs. passing a string representing
the name of an object.

So I was not illustrating the OP's proposal, but showing (but not
proposing) a modified version of it that acts more like decorators today,
so that we would have this:

# NOT THE OP's PROPOSAL -- more consistent with decorators today, but not
as quickly useful on its own
@decorator("spam this") var
#  decorator("spam this")("var")

..rather than this:

# OP's PROPOSAL
@decorator("spam this") var
#  decorator("spam this", "var")


> The current variable decorator
> proposal on the table is for this:
>
> @decorator(spam) name
> # --> name = decorator("name", spam)
>
> rather than what you wrote:
>
> # name = decorator("spam")("name")
>
> So I can't tell whether the difference between your version and the OPs
> is a bug or a feature :-)
>

Yes, I am not proposing this behavior or saying it was the OP's, just
illustrating to agree with you that it is so different from current
decorator behavior, I don't think it should be considered (even though I
sort of like how it looks).


> > For this reason I think I would agree even more so that the differences
> in
> > the decorator behavior would be an extremely significant point of
> confusion.
> [...]
> > Maybe employment of decorator syntax could OPTIONALLY trigger a new
> dunder
> > method-- here I'll just call it __decoration_call__-- with the signature:
> >
> > def  __decoration_call__(self, obj: Any, by_name: str) -> Any: ...
>
> To be clear here, I think that your proposal is that this method is to
> be looked up on the *decorator*, not the thing being decorated. Is that
> correct?
>

Yes, it is looked up on the decorator, i.e., the result of the expression
immediately to the right of the @ symbol. So it is only used when
using *decorator
syntax* (i.e., the @ symbol).


> In other words:
>
> @decorator
> class X: ...  # or a function, or something else
>
> it is *decorator*, not X, that is checked for a `__decoration_call__`
> method.
>
> Correct?
>

Yes.


> > My idea is to optionally allow any callable object to write a
> > __decoration_call__ method that gets called in lieu of the __call__
> method
> > when the callable object is employed using decorator syntax. When this
> > happens, the decorated named is supplied- not counting self- as the first
> > argument (e.g., by_name), which contains the str value of the name the
> > decorator was applied to.
>
> In current Python, the only objects which can be decorated with the @
> syntax are callable functions and classes. So it is ambiguous to talk
> about "any callable object" without stating whether it is the decorator
> or the thing being decorated.
>

I am sorry, I thought I made this clear early on in the proposal. yes, the
decorator is the thing. More precisely, the result of the expression to the
right of the @ symbol.

By "any callable", I had in mind how any callable can be used as a
decorator (so long as it isn't expecting more than 1 positional argument
and no required kwd arguments). But really, the result any expression can
be a decorator now (as of 3.10 I believe?), thought you might get an error:

@1/2
def func(): ...
# TypeError: 'float' object is not callable


> > In actuality, unless I'm wrong (I might be; not an expert) current
> > deco

[Python-ideas] Re: Add static variable storage in functions

[Ricky Teachey]

On Thu, May 27, 2021 at 8:19 AM Steven D'Aprano  wrote:

> On Thu, May 27, 2021 at 07:56:16AM -, Shreyan Avigyan wrote:
>
> > This idea proposes to add a keyword
> > (static, maybe?) that can create static variables that can persist
> > throughout the program yet only accessible through the function they
> > are declared and initialized in.
>
>
> Here is a sketch of how this could work, given a function like this:
>
> def func(arg):
> static spam, eggs
> static cheese = expression
> ...
>
>
> At function declaration time, the two static statements tell the
> compiler to:
>
> * treat spam, eggs and cheese as local variables (use LOAD_FAST instead
>   of LOAD_GLOBAL for lookups);
>
> * allocate static storage for them using the same (or similar) mechanism
>   used for function default values;
>
> * spam and eggs get initialised as None;
>
> * cheese gets initialised to the value of `expression`, evaluated
>   at function declaration time just as default arguments are.
>
>
> When the function is called:
>
> * the interpreter automatically initialises the static variables
>   with the stored values;
>
> * when the function exits (whether by return or by raising an
>   exception) the static storage will be updated with the current
>   values of the variables.
>
> As a sketch of one possible implementation, the body of the function
> represented by ellipsis `...` might be transformed to this:
>
> # initialise statics
> spam = LOAD_STATIC(0)
> eggs = LOAD_STATIC(1)
> cheese = LOAD_STATIC(2)
> try:
> # body of the function
> ...
> finally:
>STORE_STATIC(spam, 0)
>STORE_STATIC(eggs, 1)
>STORE_STATIC(cheese, 2)
>
>
>
Couldn't you already get pretty close to this by attaching your static
values to the function __dict__?

Example:

def func():
print(func.a)
func.a = 1

Usage:

 >>> func()
 1

Of course that is slower because there is an attribute lookup.

But could there be a decorator that links the function __dict__ to
locals(), so they are intertwined?

@staticify({ 'a':1})
def func():
print(a)
print(b)
func.b = 2

Usage:

 >>> func()
 1
 2
 >>> func.a = 3  # dynamic update of func.__dict__
 >>> func()
 3
 2

The locals dict in the function body would look something like this:

ChainMap(locals(), {'a':1})

---
Ricky.

"I've never met a Kentucky man who wasn't either thinking about going home
or actually going home." - Happy Chandler


> One subtlety: what if the body of the function executes `del spam`? No
> problem: the spam variable will become undefined on the next function
> call, which means that subsequent attempts to get its value will raise
> UnboundLocalError:
>
>
> try:
> x = spam + 1
> except UnboundLocalError:
> spam = 0
> x = 1
>
>
> I would use this static feature if it existed. +1
>
>
>
> --
> Steve
>

 Same thing would happen with my idea: del a would delete a from the
func.__dict__ (just like with ChainMap). But if you add it back again
later, it would not be static anymore.

Example:

@staticify('a': 1)
def func():
print(a)  # fast static lookup
del a  # static is deleted
a = 2  # this is local now
func.b = 3  # but this is a static
___
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/SB4PZLYCTKRWHNXWVFWIXQC3NEZQRKQL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: A __decoration_call__ method for Callable objects (WAS: Decorators on variables)

[Ricky Teachey]

On Wed, May 26, 2021 at 2:22 PM Matt del Valle  wrote:

> I'm still digesting this proposal (though I think I like it quite a bit),
> but there's one thing in particular that just really doesn't gel with me.
>
> Is there any particular reason why you've proposed assignment decorators
> as being on the same line as the assignment statement rather than on the
> preceding line(s)?
>

No reason, very bikesheddable.

I like this:
>
> @typing.TypeVar
> T = str, bytes
>
>
> about a million times better than:
>
> @typing.TypeVar T = str, bytes
>
>
> Because the latter feels (to me) too similar for comfort to this:
>
> int foo = 3
>
>
> Which is in my mind not very pythonic. Also, my brain just has an easier
> time parsing the multiline version than the single-line one (though I
> concede that a combination of familiarity and syntax highlighting would
> solve that issue eventually).
>
> It also represents an asymmetry between the syntax of the proposed
> assignment decorators and the syntax for function and class decorators.
>
> And finally, it doesn't cleanly accommodate use-cases like those proposed
> by Stéfane in the previous thread:
>
> @acl(READ, WRITE)
> @constraint(10 < _ < 100)
> @not_null
> @indexed
> @depends_on(whatever)
> @inject
> first_name: str
>
>
> Whereas the multiline variant does.
>
> Another question I've got is whether you've got any solution in mind for
> more complex assignment cases?
>

I do not as of yet. Still thinking about it.


> After thinking about the proposals in the Steven's thread (the googly-eye
> symbol), I think I'm a fan of providing the name as a *tuple of tuple of
> strings*, like so:
>
> @decorate
> foo = first, _, third, *rest = bar = [0, 1, 2, 3, 4]
>
>
> such that __decoration_call__ receives the following tuple for its second
> argument:
>
> (('foo',), ('first', '_', 'third', '*rest'), ('bar',)
>
> And it can then choose to do whatever it likes with all the available
> names without having to implement its own logic for parsing the names back
> out from a string.
>
> My only other question would be, what would you think of adding a third
> argument to pass the type hint along? Function decorators can always access
> the __annotations__ on the function object they act on, but currently your
> __decoration_call__ can't capture type information. With such an argument,
> this:
>
> @decorate
> foo: int = 3
>
>
> Would be provided to 'decorate' as:
>
> def __decoration_call__(self, obj, names, annotation):
> print(obj)  # 3
> print(names)# (('foo',),)
> print(annotation)   # int
>
>
I'd not be opposed.

Another (fourth) argument could be the code object from the RHS (if
inspect.getsource can't be shoehorned into getting it for us).

---
Ricky.

"I've never met a Kentucky man who wasn't either thinking about going home
or actually going home." - Happy Chandler
___
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/25FRSQJJPY3SLH3D3SXLNRO2H4IBMDO4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: A __decoration_call__ method for Callable objects (WAS: Decorators on variables)

[Ricky Teachey]

I made a mistake. This sentence:

My idea is to optionally allow any callable object to write a
> __decoration_call__ method that gets called in lieu of the __call__ method
> when the callable object is employed using decorator syntax. When this
> happens, the decorated named is supplied- not counting self- as the first
> argument (e.g., by_name), which contains the str value of the name the
> decorator was applied to.


Should read:

My idea is to optionally allow any callable object to write a
__decoration_call__ method that gets called in lieu of the __call__ method
when the callable object is employed using decorator syntax. When this
happens, the decorated named is supplied- not counting self- as the
*SECOND* argument
(e.g., by_name), which contains the str value of the name the decorator was
applied to.

---
Ricky.

"I've never met a Kentucky man who wasn't either thinking about going home
or actually going home." - Happy Chandler


On Wed, May 26, 2021 at 12:43 PM Ricky Teachey  wrote:

> On Wed, May 26, 2021 at 7:54 AM Steven D'Aprano 
> wrote:
>
>> On Wed, May 26, 2021 at 01:33:07PM +0200, Stéfane Fermigier wrote:
>>
>> > Last point that I like in the decorator syntax: it's
>> >
>> > I can compose N different decorators and keep the intent obvious:
>> >
>> > @acl(READ, WRITE)
>> > @constraint(10 < _ < 100)
>> > @not_null
>> > @indexed
>> > @depends_on(whatever)
>> > @inject
>> > @...
>> > first_name: str
>>
>> Hmm, that's a good point.
>>
>> On the other hand, it would be terribly confusing if the same syntax:
>>
>> @decorate
>>
>> had radically different meaning depending on whether it was followed by
>> a class/function or a bare name.
>>
>>
>> --
>> Steve
>>
>
> and previously Steve also said:
>
> On Tue, May 25, 2021 at 3:28 AM Steven D'Aprano 
> wrote:
>
>> On Mon, May 24, 2021 at 06:36:47PM -0700, micro codery wrote:
>>
>> > Basically this would add syntax to python that would transform
>> > @decorator("spam this") variable
>> > into
>> > variable = decorator("variable", "spam this")
>>
>> That is confusingly different from decorator syntax in other contexts
>>
>> @decorator("spam this")
>> def func(): pass
>>
>> # transformed to:
>>
>> def func(): pass
>> func = decorator("spam this")(func)
>>
>> ...the critical difference is that the argument "spam this" should be
>> passed to the decorator *factory*, which then returns the actual
>> decorator that gets applied to the variable. (Or function/ class in the
>> case of regulator decorator syntax.)
>
>
> Well, in actuality even if it were implemented the way you described, it
> is still going to be very different--- I might even say radically different.
>
> These two ideas of a decorator syntax result are not the same:
>
> RESULT A: function decorator
> # func = decorator("spam")(func)
>
> RESULT B: variable decorator
> # name = decorator("spam")("name")
>
> ...because func is passed as an object, but "name" a string representing
> the name of the object. Two very different things.
>
> For this reason I think I would agree even more so that the differences in
> the decorator behavior would be an extremely significant point of confusion.
>
> This got me to thinking: what if access to the variable name were provided
> by another means, and ONLY when the decorator syntax is employed?
>
> So then I started to write this big long email and it kind of got out of
> hand. Hopefully it isn't a disaster.
>
> FIRST LAYER: RICK'S (LIKELY HALF-BAKED) COUNTER PROPOSAL
>
> Maybe employment of decorator syntax could OPTIONALLY trigger a new dunder
> method-- here I'll just call it __decoration_call__-- with the signature:
>
> def  __decoration_call__(self, obj: Any, by_name: str) -> Any: ...
>
> Before I describe what I intend by this, first I will stipulated that what
> I am proposing here should only be implemented so that the behavior of all
> currently existing decorators (i.e., all callables) would remain exactly as
> it does today.
>
> So, for any existing callable with the name decorator, this:
>
> @decorator("spam this")
> def func(): ...
>
> ...continues to mean this, just as it does today:
>
> def func(): ...
> func = decorator("spam this")(func)
>
> My idea is to optionally allow any callable object to write a
> __d