Bruce Leban writes:
> where *!j* means join. It could optionally take a separator string as in
> this example:
Converters *could* take arguments but they currently don't: it's a
simple switch on a str argument.
We already have one complex minilanguage inside {}, do we really want
another?
May
Paul Bryan writes:
> It largely focuses on content. Would it be worth codifying additional
> aesthetic and usability objectives, and build consensus around
> them?
We're literally talking about painting a bikeshed! Just do it, and if
people don't like it enough it gets rolled back.
My two se
On Mon, May 03, 2021 at 11:49:31AM -0700, Christopher Barker wrote:
> To be clear, I'm -1 as well -- we just don't need it. but a few thoughts:
>
> On Mon, May 3, 2021 at 6:32 AM Steven D'Aprano wrote:
> > If we have str comprehensions, we'd need at least two prefixes: one for
>
> > raw strings
First of all, the reason that private members can be hacked in C++ because of
pointers. I don't know Java, so I don't know how it's possible there. But
Python doesn't have pointers and getattr, settatr can be adjusted to work with
private members. The only way the hack is possible if someone wro
On Thu, May 6, 2021 at 10:49 PM Shreyan Avigyan
wrote:
> The benefit of private is actually debugging. If somehow, someone finds that
> the private member has changed they would immediately know that it was a
> memory leak or the value was changed through a set method defined in the
> class (Th
Please read my whole comment.
___
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.o
Most of the time when someone fixes a bug using a private member of another
class then it's completely considered private code. Sometimes applications can
cause crashes if there's memory leak or modification. Like there's an example
where you change the name attribute of a bank account class and
On Thu, May 6, 2021 at 11:14 PM Shreyan Avigyan
wrote:
>
> Please read my whole comment.
Please actually quote some text so we know who you're responding to,
what you're talking about, etc.
ChrisA
___
Python-ideas mailing list -- [email protected]
On 2021-05-06 12:46:40, Shreyan Avigyan wrote:
> But Python doesn't have pointers and getattr, settatr can be adjusted
> to work with private members.
Not really, this is explicitly mentioned on the docs.
Here's an example:
> >>> from dataclasses import dataclass
> >>> @dataclass(frozen=True)
>
Chris :-
> Please actually quote some text so we know who you're responding to,
what you're talking about, etc.
I'm actually telling to read my comment here
https://mail.python.org/archives/list/[email protected]/message/426EPANCVEGZV2AZL7MWNG67BTZMORNG.
See the Conclusion section in there
On Thu, May 6, 2021 at 10:16 AM Shreyan Avigyan
wrote:
> Most of the time when someone fixes a bug using a private member of
> another class then it's completely considered private code. Sometimes
> applications can cause crashes if there's memory leak or modification. Like
> there's an example w
Again. See what I suggested. I changed my suggestion from "Private" to
"Non-modifiable member variables".
___
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailm
On Thu, May 6, 2021 at 11:22 AM Shreyan Avigyan
wrote:
Quoting the entire content:
Again. See what I suggested. I changed my suggestion from "Private" to
> "Non-modifiable member variables".
>
I have no idea if this is in response to my own email or someone else as
you do not include any context
André Roberge:
> My own email specifically referred to two instances where I found it
necessary to **modify** methods that are indicated as being private as
their names begin with double underscores. So, I am strongly opposed to
your suggestion.
Actually as I explained in this comment
https://mai
On 5/6/21 6:26 AM, Shreyan Avigyan wrote:
> Chris wrote:
>> Please actually quote some text so we know who you're responding to,
>> what you're talking about, etc.
>
> I'm actually telling to read my comment here
https://mail.python.org/archives/list/[email protected]/message/426EPANCVEGZV
I am a strong -1 on this.
On Thu, May 6, 2021 at 2:41 PM Shreyan Avigyan
wrote:
> André Roberge:
> > My own email specifically referred to two instances where I found it
> necessary to **modify** methods that are indicated as being private as
> their names begin with double underscores. So, I am
David Mertz:
> I am a strong -1 on this
Thanks for your feedback. But I'm not suggesting introducing a new behavior.
The @property already creates read-only member variables. What I'm suggesting
is that introducing a new keyword or decorator as required to create a variable
that can be modified
On Fri, May 7, 2021 at 12:44 AM Ethan Furman wrote:
>
> On 5/6/21 6:26 AM, Shreyan Avigyan wrote:
> > Chris wrote:
>
> >> Please actually quote some text so we know who you're responding to,
> >> what you're talking about, etc.
> >
> > I'm actually telling to read my comment here
> https://ma
On Fri, May 7, 2021 at 1:12 AM Shreyan Avigyan
wrote:
>
> David Mertz:
> > I am a strong -1 on this
>
> Thanks for your feedback. But I'm not suggesting introducing a new behavior.
> The @property already creates read-only member variables. What I'm suggesting
> is that introducing a new keyword
Chris:
> That would require some definition of what's "within" and what's
> "outside" the class, and whatever definition you use, it won't work
> with all forms of dynamic code.
Yes, implementing that will be hard. But the question is I can't quite
understand why this is not acceptable by the Py
On Fri, May 7, 2021 at 4:04 AM Shreyan Avigyan
wrote:
>
> Chris:
>
> > That would require some definition of what's "within" and what's
> > "outside" the class, and whatever definition you use, it won't work
> > with all forms of dynamic code.
>
> Yes, implementing that will be hard. But the quest
I *have* used @property to suggest that variables be read-only.
That said, I believe that using the (I believe fairly common) pattern of
defining a property as a no-op wrapper around a corresponding "private"
(single underscore) attribute tends to be a more pythonic solution to the
read-only dilem
Chris:
> I'm not sure about other people, but I have never, not once, used
> @property as a means of controlling access. So giving me another way
> to do something that I am not, and don't want to, do... isn't much of
> an argument. :)
Ok. I'm giving you another example that doesn't cause security
On 2021-05-06 at 18:34:55 -,
Shreyan Avigyan wrote:
> Chris:
> > I'm not sure about other people, but I have never, not once, used
> > @property as a means of controlling access. So giving me another way
> > to do something that I am not, and don't want to, do... isn't much of
> > an argument
On Thu, May 6, 2021, 11:12 AM Shreyan Avigyan
wrote:
> David Mertz:
> > I am a strong -1 on this
>
> Thanks for your feedback. But I'm not suggesting introducing a new
> behavior. The @property already creates read-only member variables. What
> I'm suggesting is that introducing a new keyword or
The problem is that whatever programming language it is, there's always a hack
to do things. And since it also doesn't make sense to introduce readonly
function names (What a terrible nightmare!), maybe readonly variable also
doesn't make sense to be added. Anyway, this was quite a discussion. T
06.05.21 15:46, Shreyan Avigyan пише:
> But Python doesn't have pointers and getattr, settatr can be adjusted to work
> with private members.
It doesn't work this way. You cannot distinguish the use of getattr()
which breaks encapsulation from the one which does not. Inside getattr()
you only hav
On Thu, May 06, 2021 at 03:09:33PM -, Shreyan Avigyan wrote:
> What I'm suggesting is that introducing a new keyword or decorator as
> required to create a variable that can be modified from within the
> class but not outside the class.
That's an interesting suggestion, but how do you defin
Steven D'Aprano:
> My guess is that you have used a lot of Java, or at least read a lot of
> Object Oriented Programming theory that is based on the Java model
I've never used Java. I don't even know Java so well. But the Java and C++
model is similar and since I know C/C++ I'm guessing about Ja
On 5/6/21 10:44 PM, Shreyan Avigyan wrote:
> Anyway this thread is closed.
As you may have noticed, this is a mailing list -- no thread is closed. I've
seen posts to three-year-old threads.
--
~Ethan~
___
Python-ideas mailing list -- python-ideas@py
Ethan:
> As you may have noticed, this is a mailing list -- no thread is closed. I've
> seen posts to three-year-old threads.
Since the discussion has come to a halt and it's decided that we'll continue to
use the Pythonic way for private and it's also very hard to implement what I
suggested,
31 matches
Mail list logo
