[Python-ideas] Re: Extract variable name from itself

[Bruce Leban]

If the goal is to create a syntax that allows tools to recognize names in
strings, there is a simple solution which requires tool changes only, for
example:

raise Exception('The field ' + ((('size'))) + ' must be a positive integer
in ' + ((('Sample.widget'

Python already treats triple parenthesized strings properly and all you
need to do is modify tools to recognize that syntax. It's even backwards
compatible, visually striking, and doesn't prevent compile-time string
folding.

--- Bruce

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

[Python-ideas] Re: Warn when iterating over an already exhausted generator

[Bruce Leban]

I think the discussion is sort of missing a very common use case, when a
user calls func(iterator) and the function is expecting an iterable but not
an iterator. The author of the called code might be thinking that the input
is a list but that doen't mean the caller thinks that. Even worse is a case
like this:

def func(data_list):
if VERBOSE:
log(... [ ... for i in  data_list  ... ] ...)
for i in  data_list :
do stuff with i

The behavor of this code changes (significantly!) when VERBOSE is set.
That's going to make debugging hard. [Yes, I know this can be safely
written using itertools.tee. That doesn't mean that everyone will do that.]
Here's a simple way to describe what the behavior could be (although
obviously this doesn't work):

def safer_iter_behavior(iterator):
yield from iterator
raise StopIteration
raise RuntimeError

That is, when you iterate the first time, it acts as expected, raising
StopIteration when the list is exhausted. If you continue to iterate after
the list is exhausted, it raises RuntimeError. In addition to the double
iteration case above, it guards against other cases like:

for x in iterator1:
y = next(iterator2)
do stuff

when the iterator2 is unexpectedly shorter than iterator1. Of course,
naively guarding against that by adding

if len(iterator1) != len(iterator2): ...

would be a bad idea and would also result in RuntimeError.

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

[Python-ideas] Re: Allowing `str.format` to format one or more parameters instead of all parameters

[Bruce Leban]

On Tue, Apr 25, 2023 at 6:16 PM Joao S. O. Bueno  wrote:

>
> Worst case scenario, one goes from one non-running program to a running
> program producing partially incorrect output. Any legacy code that was not
> working in the first place, is obviously, clearly, not critical for anyone,
> otherwise it would have been fixed already.
>

Worst case scenario: use of this feature introduces bugs. For example,
security holes.

Generally, formatting and parsing are not idempotent and you should not
reformat or reparse already processed strings. See
http://google-gruyere.appspot.com/ to learn more about the pitfalls and in
particular
http://google-gruyere.appspot.com/part5#5__information_disclosure_bug_3


On Fri, Apr 28, 2023 at 8:49 AM MRAB  wrote:

>
> What happens if you do '{open}...{close}'.partial_format(open='{close}'?
> You get '{close}...{close}', and you're going to have a problem using
> that as a format string and replacing only the second '{close}'.
>

To take this further, suppose you write 'Hello {username} from
{company}'.format(userdata).format(companydata) where the user has set
their name to "Dr. {secret} Evil" where {secret} is something in companydata
that should not be exposed. The presence of this bug is going to be very
hard to find.

This seems like an obvious case of a non-solution to a non-problem that's
actually worse than no solution at all.

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

[Python-ideas] Re: join() could add separators at start or end

[Bruce Leban]

On Wed, Mar 8, 2023 at 4:34 PM Rob Cliffe via Python-ideas <
python-ideas@python.org> wrote:

> It seems to me that it would be useful to be able to make the str.join()
> function put separators, not only between the items of its operand, but
> also optionally at the beginning or end.
> E.g. '|'.join(('Spam', 'Ham', 'Eggs')) returns
>  'Spam|Ham|Eggs'
> but it might be useful to make it return one of
>  '|Spam|Ham|Eggs'
>  'Spam|Ham|Eggs|'
>  '|Spam|Ham|Eggs|'
>

Compare these two lines:

'\n'.join(lines) + '\n'
'\n'.join(lines, atEnds=1)



The first is not only shorter, it's more clear what it's doing. I'd have to
look up everytime to remember whether the value atEnds=1 is doing the right
thing. It's just IMHO not valuable enough for the cost. Not every potential
optimization is worth including in the core language or the stdlib (if this
even is an optimization).

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

[Python-ideas] Re: Ampersand operator for strings

[Bruce Leban]

On Sun, Mar 5, 2023 at 7:39 PM Rob Cliffe via Python-ideas <
python-ideas@python.org> wrote:

> Tl;dr: Join strings together with exactly one space between non-blank
>

This idea is inappropriate for inclusion in the language. There are too
many subtle details in how this should work as noted by others. To give an
example which I hope clearly illustrates that this is not simple,

what should the value of 'ｆｕｌｌ' & 'ｗｉｄｔｈ' be?

   - 'ｆｕｌｌ ｗｉｄｔｈ'
   - 'ｆｕｌｌ ｗｉｄｔｈ'

In case it's not clear, those are full width Latin characters which should
be joined by a full width (ideographic) space U+3000. What should be
inserted when the characters are Kanji (which doesn't usually use spaces)
or Amkharic (which uses '፡' U+1361) or a mix of different character sets?

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

[Python-ideas] Re: Idea: Tagged strings in python

[Bruce Leban]

On Sat, Dec 17, 2022 at 10:10 AM  wrote:

>
> I replied to this in a separate post, but html() is likely a function name
> that is used in millions of existing code bases. Applying this rule to all
> of them will lead to too many errors to be acceptable to editors I think.
> And if this has to be explicitly configured in an editor very few will use
> it.
>

Understood. This string suffix syntax is supported by Python today and
syntax highlighters could be modified to support this without requiring
changes to any other component.

class Calendar(component.Component):
template_string = '' ##html
css_string = '.calendar { background: pink }' ##css
js_string = 'document.getElementsByClassName("calendar")[0].onclick =
function() { alert("click!") }' ##javascript

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

[Python-ideas] Re: Idea: Tagged strings in python

[Bruce Leban]

On Sat, Dec 17, 2022 at 9:43 AM  wrote:

>
> Your reply could easily be read as "this is a bad idea, and you shouldn't
> have bothered writing it down". I hope that was not your intention, and
> instead it comes from handling self-indulgent people expecting things from
> you all day. I know, I get those requests too. I'll assume that was not
> your intention in my answers below.


>
Barry Scott wrote:
> > I think this has been discussed before and rejected.
>
> Do you have a link to that discussion, or is this just from memory? What
> should I search for to find this discussion? Why was it rejected?
>

Try googling "python-ideas string prefixes". Doing mimimal diligence is a
reasonable expectation before writing up an idea.

> If the tags are called as functions then you can do it today with this:
> > def html(s):
> > return s
> > HEAD = html('')
>
> If I'm not missing anything, this doesn't help with syntax highlighting?
> Highlighting is the problem I'm talking about in my post above.
>

Not true. A syntax highlighter can certainly recognize html('...') just as
it can recognize html'...'.

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

[Python-ideas] Re: Enhancing variable scope control

[Bruce Leban]

On Sun, Dec 4, 2022 at 11:08 AM Chris Angelico  wrote:

>
>
> You're not the first to try to use globals() for this, but it means
> that the context manager works ONLY at top-level.
>

 I agree with most criticism of this proposal, although I'll note that the
one place where I'd like something like this is at top level. I often write
something like this at top level:

__part1 = (some calculation)
__part2 = (some other calculation)
THING = combine(__part1, __part2)
__part1 = __part2 = None

If they are large objects and I forget to explictly delete the references,
then they won't be garbage collected. Yes, this trivial example could be
folded into a single line but that makes it much harder to understand what
it's doing. And often those calculations are more complex and can't be
written on one line. I can put that in a function which still leaves the
function in scope:

def __create_thing():
part1 = (some calculation)
part2 = (some other calculation)
return combine(part1, part2)
THING = __create_thing()

If we had a top-level-only local statement, I might use it but note that
it's still clumsy since I have to make THING non-local:

local:
part1 = (some calculation)
part2 = (some other calculation)
nonlocal THING
THING = combine(part1, part2)

The often-rejected multi-line lambda might be better except those parens at
the end are easy to miss:

THING = (lambda:
part1 = (some calculation)
part2 = (some other calculation)
return combine(part1, part2))()

Looking at all these options, is the cost of adding anything actually worth
the benefit? Probably not.

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

[Python-ideas] Re: Add InvalidStateError to the standard exception hierarchy

[Bruce Leban]

On Thu, Sep 1, 2022 at 2:57 PM Jean Abou Samra  wrote:

>
> How would
> a "state error" differ from this more precisely? What value would this new
> exception type add? Both ValueError and this proposed StateError are very
> generic.
>

 Some examples:

* a stream-like object that has been closed and you attempt to read from or
write data to it.

* a random number generator that has not been initialized with a seed (in
the case where you have a constructor which doesn't also initialize it).

* a hash function which you try to compute the digest without having added
any data to it.

In all these cases, the current call fails because a *previous* call was
not done. The parameters to this invocation are not by themselves incorrect.

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

[Python-ideas] Re: Add InvalidStateError to the standard exception hierarchy

[Bruce Leban]

Java calls this IllegalStateException so I would suggest IllegalStateError.

Looking at other exceptions that Java has, it would also be nice to
have UnsupportedOperationError (I have used NotImplementedError for this
but that suggests it might someday be implemented).

On the other hand, as you noted, it's fairly trivial to implement new
exceptions where needed.

--- Bruce




On Thu, Sep 1, 2022 at 2:41 PM Steve Jorgensen  wrote:

> I frequently find that I want to raise an exception when the target of a
> call is not in an appropriate state to perform the requested operation.
> Rather than choosing between `Exception` or defining a custom exception, it
> would be nice if there were a built-in `InvalidStateError` exception that
> my code could raise.
>
> In cases where I want to define a custom exception anyway, I think it
> would be nice if it could have a generic `InvalidStateError` exception
> class for it to inherit from.
>
> Of course, I would be open to other ideas for what the name of this
> exception should be. Other possibilities off the top of my head are
> `BadStateError` or `StateError`.
> ___
> 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/NMHNKSEZG7UZ6AIFTVGQXVECCNYYVODT/
> 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/R56RBM25NENOV6DPCZ6SUD325BGJS26S/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Regex timeouts

[Bruce Leban]

On Mon, Feb 14, 2022 at 9:55 AM J.B. Langston 
wrote:

> ... more generally I think it would be good to have a timeout option that
> could be configurable when compiling the regex so that if the regex didn't
> complete within the specified timeframe, it would abort and throw an
> exception.
>
> ... The suggestion made to me on the bug was to read Mastering Regular
> Expressions and get better at writing regexes. I will take this advice, but
> this isn't really a reasonable solution to my problem for a few reasons.
> My use case is log parsing and I have a large number of regexes that run
> over many different log lines. With the volume of regexes I have, it's hard
> to make sure every regex has no potential problems, especially when the
> pathological behavior only occurs on certain inputs that may not have been
> anticipated when developing the regex.
>

A regex that's vulnerable to pathological behavior is a DoS attack waiting
to happen. Especially when used for parsing log data (which might contain
untrusted data). If possible, we should make it harder for people to shoot
themselves in the feet.

As an aside, pure regex's are not vulnerable, only extended regex. However,
Python doesn't (that I know of) have a class that only accepts pure regex.

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

[Python-ideas] Re: Please consider mentioning property without setter when an attribute can't be set

[Bruce Leban]

I think the more useful message would be something along the lines of

AttributeError: can't set attribute 'f' on object of type 'D'

This will help you track down the error. Steven D'Aprano listed three
reasons why it might fail which sounds right but frequently the underlying
reason is something else:

You're trying to set the attribute on the wrong object (e.g., element.color
vs. element.style.color). I wish more error messages identified the types
of the objects involved.

--- Bruce

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

[Python-ideas] Re: Mapping unpacking assignment

[Bruce Leban]

On Thu, Feb 3, 2022 at 11:53 AM Yurii Karabas <1998uri...@gmail.com> wrote:

>
> Proposed syntax:
>
> m = {"a": 1, "b": 2, "c": 3, "d": 4}
>
> {a, b} = m # a: 1, b: 2
> {a, b, **rest} = m # a: 1, b: 2, rest: {c: 3, d: 4}
>
> as equivalent to this from PEP 634:


> match m:
> case {"a": a, "b": b, **rest}:
> pass
> case _:
> raise ValueError


What I find particularly unsatisfying is that the left hand side syntax in
your proposal {a, b, **rest} is not at all like, the case syntax {"a": a,
"b": b, **rest} so that's twice as much syntax to learn.
*IF* this is really used often enough that it is worth adding to the
language it should be a variation of match, something like:

match m as  {"a": a, "b": b, **rest}

The match clause defaults to doing nothing if the value doesn't match but
that's less useful here (and harder to deal with since figuring out that a,
b, and rest are still unbound is clumsy, so I would agree that it should
raise ValueError if there's no match.

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

[Python-ideas] Re: Unit variables upon their first appearance

[Bruce Leban]

On Sat, Feb 5, 2022, 12:19 PM Mirmojtaba Gharibi 
wrote:

>
> With my proposal, using := to init (similar to how in math parlance, the
> := is used for defining something for the first time)
>
> Dic =  {} # format fruit:count
> For fruit in fruits:
>Dic[fruit]:= 0
>Dic[fruit]+=1
>

To my eye, this does not look like a conditional assignment. And how would
an operator like this work with objects other than dicts?

Besides, it's easier and clearer to write this as

dic = defaultdict(int)
for fruit in fruits:
dic[fruit] += 1

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

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

[Bruce Leban]

On Sat, Oct 23, 2021 at 7:55 PM Steven D'Aprano  wrote:

>
> And is it really a problem if we delay the late-binding to the point
> where the value is actually needed? ...

   



[in that csse] I would stick to manual late-
> binding using None, and only evaluate it as needed.
>
> Maybe this is an argument for some sort of thunk, as in Algol, which is
> only evaluated at need.
>



I have no idea whether thunk-like functionality is workable in Python's
> execution model without slowing down every object reference, but if it
> is possible, there could be other really nice use-cases beyond just
> function defaults.
>

 Your message here and my message on this passed in the mail. Yes, this is
a really good point and would apply to the cases I've seen where the
evaluation was in the middle. Thanks for raising it. I also don't know if
it's workable but it should be considered.

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

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

[Bruce Leban]

--- Bruce




On Sat, Oct 23, 2021 at 7:55 PM Chris Angelico  wrote:

> On Sun, Oct 24, 2021 at 1:48 PM Bruce Leban  wrote:
> >
> >
> > On Sat, Oct 23, 2021 at 6:23 PM Jelle Zijlstra 
> wrote:
> >>
> >> In the PEP's example:
> >>
> >> def bisect_right(a, x, lo=0, hi=>len(a), *, key=None):
> >>
> >> This reads to me like we're putting "hi" into "len(a)", when it's in
> fact the reverse.
> >
> > Every language I am aware of that has adopted a short hand lambda
> notation (without a keyword) has used => or -> except APL, Ruby, SmallTalk.
> See https://en.wikipedia.org/wiki/Anonymous_function
>
>
> Anonymous functions are an awkward parallel here. The notation you're
> describing will create a function which accepts one argument, and then
> returns a value calculated from that argument. We're actually doing
> the opposite: hi is being set to len(a), it's not that len(a) is being
> calculated from hi.
>
> That said, though, I still count "=>" among my top three preferences
> (along with "=:" and "?="), and flipping the arrow to "<=" is too
> confusable with the less-eq operator.
>

Sorry I was less than clear. The syllogism here is

(1) late-evaluated argument default should use => because that's the
proposal for shorthand lambda

(2) shorthand lambda should use => because that's what other languages use.

I was talking about (2) but I should have been explicit. And yes, you
highlight a potential source of confusion.

def f(x=>x + 1): ...

means that x is 1 more than the value of x from the enclosing global scope
(at function call time) while

g = x => x + 1

sets g to a single-argument function that adds 1 to its argument value.

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

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

[Bruce Leban]

On Sat, Oct 23, 2021 at 7:00 PM Steven D'Aprano  wrote:

> I challenge that assertion. I've never knowingly seen a function where
> the late binding is "buried deeper in the function", certainly not deep
> enough that it is not obvious. It is a very strong convention that such
> late binding operations occur early in the function body.
>
> You know, before you use the parameter, not afterwards *wink*
>

I've seen this and recently. The case is where the evaluation of the
default expression might be expensive, and is only used depending on the
value of other arguments.

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

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

[Bruce Leban]

On Sat, Oct 23, 2021 at 6:23 PM Jelle Zijlstra 
wrote:

> In the PEP's example:
>
> def bisect_right(a, x, lo=0, hi=>len(a), *, key=None):
>
> This reads to me like we're putting "hi" into "len(a)", when it's in fact
> the reverse.
>

I think in most cases what's on the right side will be something that's not
assignable. Likewise with the proposal to use => for lambda, someone could
read (a => a + 1) as putting a into a + 1. I think they're going to get
over that.

Every language I am aware of that has adopted a short hand lambda notation
(without a keyword) has used => or -> except APL, Ruby, SmallTalk. See
https://en.wikipedia.org/wiki/Anonymous_function

APL uses a tacit syntax while Ruby and SmallTalk use explicit syntaxes. The
equivalent of x => x + 1 in each of these is

APL ⍺+1   (I think)
Ruby|x| x + 1
SmallTalk   [ :x | x + 1 ]


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

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

[Bruce Leban]

On Sat, Oct 23, 2021 at 12:56 PM Guido van Rossum  wrote:

> I like that you're trying to fix this wart! I think that using a different
> syntax may be the only way out. My own bikeshed color to try would be `=>`,
> assuming we'll introduce `(x) => x+1` as the new lambda syntax, but I can
> see problems with both as well :-).
>
>
+1 to this spelling. I started writing a message arguing that this should
be spelled with lambda because the fact that you're (effectively) writing a
function should be explicit (see below). But the syntax is ugly needing
both a lambda and a variant = operator. This solves that elegantly.

On Sat, Oct 23, 2021 at 9:10 AM Chris Angelico  wrote:

> Proposal: Proper syntax and support for late-bound argument defaults.
>
> def bisect(a, x, lo=0, hi=:len(a)):
> if lo < 0:
> raise ValueError('lo must be non-negative')


The syntax I've chosen is deliberately subtle, since - in many many
> cases - it won't make any difference whether the argument is early or
> late bound, so they should look similar.
>

I think a subtle difference in syntax is a bad idea since this is not a
subtle difference in behavior. If it makes no difference whether the
argument is early or late bound then you wouldn't be using it.

Here's one way you could imagine writing this today:

def bisect(a, x, lo=0, hi=lambda: len(a)):
hi = hi() if callable(hi) else hi
...

which is clumsy and more importantly doesn't work because the binding of
the lambda occurs in the function definition context which doesn't have
access to the other parameters.



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

[Python-ideas] Re: Looking for a PEP sponsor

[Bruce Leban]

On Wed, Jul 14, 2021 at 8:50 AM Nick Humrich  wrote:

>
> In accordance to PEP 0, I am looking for a Python-core-developer to
> sponsor my new PEP. It is essentially a revisit of PEP 501. https://
> github.com/nhumrich/peps/blob/master/pep-.rst
> 
>

By immediately calling format on your t-strings in your examples you
obfuscate what this is doing. Here's a better example:

>>> age = 50
>>> x = t'My age is {age}.'
>>> format(x)
"My age is 50."
>>> age = 51
>>> format(x)
"My age is 50."

And what about this:

>>> ages = [50]
>>> x = t'My age is {ages[0]}.'
>>> format(x)
"My age is 50."
>>> ages[0] = 51
>>> format(x)
???

However, the problem you are trying to solve and your solution seem
disconnected to me. What you propose doesn't accomplish your purpose unless
you add additional code which is not in your PEP. And it's unclear why
adding the capability to do escaping to f-strings and str.format isn't a
simpler and better solution. At the very least your PEP should discuss the
alternatives such as

f"{!!html}..."   # html escapes every string before inserting
f"{!!foobar}..." # applies the function 'foobar' to every string before
inserting
f"...{url!!foobar}"  # applies the function 'foobar' to this string value

and any others that have been proposed and weigh the pros and cons.

As I previously noted, this alternative can work for both f-strings and
str.format while your proposed t-strings will not.

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

[Python-ideas] Re: An alternate idea for escaping in string interpolation

[Bruce Leban]

Thanks for the comments, Paul and Paul.

On Sun, Jun 27, 2021 at 1:14 AM Paul Moore  wrote:

> On Sun, 27 Jun 2021 at 08:11, Paul Bryan  wrote:
> >
> > It looks like you're suggesting hard-coding specific language escape
> conventions into f-strings?
>
> That's how I understood the proposal too. Hard coding specific
> conventions shouldn't be part of a language construct IMO.
>

Yes, I am. I understand the objection that the language shouldn't know too
much about html or sql. My viewpoint is that injection attacks have been on
the OWASP Top Ten list since the inception of that list and it is unlikely
that it's going to fall off the top ten anytime soon. In my opinion
"practicality beats purity". There's a reason why many template languages
include built-in escaping operators.

> What if instead you were to allow delegation to some filter function?
> Then, it's generic and extensible.
>
> > def html(value: Any):
> > filtered = ... # filter here
> > return filtered
> >
> > f'{!!html}...'
>

As I mentioned in a footnote, a mechanism for adding conversions would be
advantageous. The specific mechanism you describe would work for f-strings
but not work for str.format. Furthermore, someone reading my suggested
{!!html}} would know what it meant while someone reading yours would have
to go read the referenced function to be sure what it did. I'm not against
such a mechanism. I'm just not sure it sufficiently addresses the injection
risk.

Well, there's already a way of handling that:
>
> f'...'
>

 That does not work for str.format, only for f-strings.

So all you're saving is a bit of typing.


I believe that this provides more clarity than your version, which of
course, I am already aware of. I also know that people are much more likely
to remember to add a single {!!html} at the front of each template than to
add {html()} everywhere. Furthermore, projects could adopt a convention of
marking all html strings (because EIBTI) and have a linter flag strings
that did not include {!!html}} or {!!}.

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

[Python-ideas] An alternate idea for escaping in string interpolation

[Bruce Leban]

This is a response in part to Thomas Güttler's "Pre PEP: Python Literals"
but I am starting a separate thread because I think it deserves separate
discussion, and it's not a direct response to that proposal.

Here's the problem: we want to allow escaping in strings to prevent
injection in HTML, SQL, etc.

Proposed solutions generally concentrate on a new kind of escaped format
string. I won't go into detail on why I don't like these ideas because
others have already covered that ground.

Instead, here's what I think is a better solution: a mechanism to allow
formatting with html and sql escaping.

Specifically, I suggest these changes:

(1) Modify string formatting (str.format and f-strings) to add new
conversions !html !sql !xml, which escape characters for embedding in html,
sql, and xml respectively.**

(2) Modify string formatting to allow these new conversions to be added to
the current conversions, e.g. !s!html.

(3) Modify string formatting to add a new syntax that specifies a
conversion to use for all subsequent interpolations. The proposed syntax is
a replacement_field that starts with two exclamation points. The
replacement field itself expands to nothing and only affects the conversion
of subsequent fields. Thus

f"{!!html}{text!r}"

is equivalent to

f"{text!r!html}"

A replacement field of {!!} resets the default conversion.

Yes, this is more typing than t-strings or backticks but EIBTI. And I
believe this expands on existing format functions in a way that will be
much more clear to someone encountering this new mechanism. And it's more
flexible as it allows more granular control of escaping as in this example:

f"""
{title!html}
{pre_rendered_html_body}
"""


**It's unclear if there's any functional benefit of having both html and
xml encoding other than clarity of usage. Also, it would be nice to have a
mechanism for adding additional conversions but I don't want to complicate
the discussion at this point. Are there other standard escape mechanisms
that would be worth including?

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

[Python-ideas] Re: Add a mechanism so that multiple exceptions can be caught using `except E1, E2, E3:`

[Bruce Leban]

On Sun, May 9, 2021 at 1:22 PM MRAB  wrote:

>
> On the third hand(!), 'as' is used in the 'import' and 'with'
> statements, where it binds to only one preceding item.
>

Thanks. Yes, that was what I was thinking that it's weird for "as" to have
different precedence in different statements, and I should have said that
explicitly.
EIBTI of course.

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

[Python-ideas] Re: Add a mechanism so that multiple exceptions can be caught using `except E1, E2, E3:`

[Bruce Leban]

On Sun, May 9, 2021 at 9:48 AM Thomas Grainger  wrote:

> now that python2.7 is EOL, it might be worth resurrecting this syntax as
> discussed in https://www.python.org/dev/peps/pep-3100/#id13
>
> eg, python 3.11 could support
> ```
> try:
> ...
> except (E1, E2, E3) as e:
> ...
> ```
>
> as equivalent to
>
> ```
> try:
> ...
> except E1, E2, E3 as e:
> ...
> ```
>

-1

I think you really mean you want Python to accept the form without the
parenthesis. I don't like it because it's easy to read that as

except E1, E2, (E3 as e):

and I don't think saving two characters is worth the disruption caused by
people being able to write Python 3.11 code that won't work in Python 3.10.
Many people would not adopt the new syntax for that reason.

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

[Python-ideas] Re: String comprehension

[Bruce Leban]

On Fri, Apr 30, 2021 at 9:06 AM David Álvarez Lombardi <
alvarezd...@gmail.com> wrote:

> I propose a syntax for constructing/filtering strings analogous to the one
> available for all other builtin iterables. It could look something like
> this.
>
> >>> dirty = "f8sjGe7"
> >>> clean = c"char for char in dirty if char in string.ascii_letters"
> >>> clean
> 'fsjGe'
>
> Currently, the best way to do this (in the general case) seems to be the
> following.
> >>> clean = "".join(char for char in dirty if char in string.ascii_letters)
>

If a feature like this is useful -- and I'm not sure it is -- there is a
much better way to do this IMHO. Add a new format converter to the syntax
for replacement fields:

*>>> f"{c for c in dirty if c in string.ascii_letters !j}"*
*'fsjGe'*

where *!j* means join. It could optionally take a separator string as in
this example:

*>>> f"{chr(65 + i) for i in range(4) !j('-')}"*
*'A-B-C-D'*

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

[Python-ideas] Re: Reverse polish notation

[Bruce Leban]

I know I'm late to the party but I think what would really help is if we
were able to use any Unicode parenthesis characters instead of just ().

Consider how much more readable this is:

b*(⧼x*2⧽^❪⦅3-a⦆-⟮7*c⟯)❫)
--- Bruce
___
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/DCCTI4VVFLHYZK6UNCHKYVSOF6LREAWI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Move semantics

[Bruce Leban]

On Thu, Nov 26, 2020 at 5:43 AM <3mi...@gmail.com> wrote:

> Add something like Move type hint to typing module. It will tell the
> analyzer that the input parameter of the function is moved and can not be
> used after. For example:
> ```
>

You say "moved and cannot be used" which is either incomplete, ambiguous,
contradictory, or some combination of those. Moved where and who can't use
it? What you really are talking about is "taking ownership." But then
you're omitting the key detail that it also gives ownership back via the
return value. Otherwise what you would want to indicate is that the
function destroys the value.

Since the semantics of Python are that objects are always passed by
reference, it's implied that control of the object is passed to the called
function. I think

What might be useful are declarations that:

   - The object is not modified (i.e., read only). If a function that
   declares a parameter as read-only passes that parameter to one that does
   not use that declaration, that can be identified as an error.
   - The object is destroyed or consumed by the function. Any use of the
   object after calling the function could be identified as an error.

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

[Python-ideas] Re: A new suggestion for Python

[Bruce Leban]

If I can, I want to back up the conversation a bit. Instead of starting
with a solution, what's the problem?

I believe the issue that this is trying to solve is that some functions
that operate on an object return a new object, and we would like to use
them to modify an object. Setting aside the fact that a new object is not
the same as a modified object and other references to that object won't
change, what this means is that we want to have a shorthand way to write:

(some reference to an object) = (an expression that operates on  are
respectively an lvalue and an rvalue.

Given that, I'll throw out a straw proposal. Since an lvalue can be
converted to an rvalue but not vice versa, suppose we rewrite this as:

(some reference) := X = 

example:

thing =: T = T.replace(before, after)


But looking at that, it really isn't much better unless the left hand side
is a very complicated expression. If we really needed a feature like this
it would be better to use a special symbol like:

thing = <>.replace(before,after)


Even then, how frequent is this pattern that it would be worth doing?

I think the answer to that question is going to be necessary to convince
anyone that the problem is worth solving.

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

[Python-ideas] Re: Changing item dunder method signatures to utilize positional arguments (open thread)

[Bruce Leban]

A bunch of the conversation here is how to handle both positional and
keyword arguments with a single signature. Let me suggest an alternative.
At compile time, we know if the call is made with keyword arguments or not.

a[1] positional only
a[b=1]   keyword only
a[1, b=1]both
a[**kwargs]  keyword only

I suggest that in the first case it calls
__getitem__(self, args)
as it does now and in the other cases it calls
__getitemx__(self, args, **kwargs)
instead (the signature is what matters here, don't bikeshed the name). Some
people have proposed arbitrary signatures for __getitemx__ but I think
that's an unnecessary degree of complexity for little benefit. Personally,
I'm not even sure I'd ever want to mix args and kwargs but including that
in the signature preserves that possibility for others that find it useful.

To explain further: when I use [...] without positional arguments the code
works exactly as it does today with all args in a tuple. Therefore, for
consistency when I add a keyword argument that should not change the args
value which is why both signatures include a single args parameter.

If you write a form that uses a keyword argument, and __getitemx__ does not
exist then it would raise an error other than KeyError (either TypeError or
AttributeError, with the latter requiring no special handling).

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

[Python-ideas] Re: Pickle security improvements

[Bruce Leban]

The security problem arises from the fact that pickle will call arbitrary
functions and that it will unpickle arbitrary classes, not just the ones
that you might intend it to.

It seems to me that the way to make pickle safe is to limit what it can
call. Unpickle can take a list of classes and it will only unpickle objects
in those classes plus the built-in types (list, tuple, etc.). I imagine
that in most cases, when you are unpickling, you have some idea of what the
thing is that you are unpickling. If an unlisted class or arbitrary
function reference is found, it raises an UnpicklingError.

There's even an example of this in the docs, but it's left to individual
developers to copy the code from the documentation:
https://docs.python.org/3.8/library/pickle.html. Why isn't this built in?

This is still vulnerable to a class being implemented in a way that doesn't
take into account how malicious unpickling might be used on it, and then
someone unknowingly pickling it. We can go one step further by adding an
__unpickle__ method that, if present, is the only method that is used to
load a class. We would also want to add a __pickle__ method.

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

[Python-ideas] Re: Add builtin function for min(max())

[Bruce Leban]

On Mon, Jul 6, 2020 at 4:27 AM Richard Damon 
wrote:

>
> > Supported, yes. Recommended, no. IEEE-754 specifies that the *minimum
> > *operation propagates NaNs while the /alternate /*minimumNumber
> > *operation drops NaNs.
>
> It should be noted, this is a change in the Standard that is just 1 year
> old. The previous version did define minimum as similar to the
> minimumNumber version.
>

Thanks for this info. I really dislike "standards" being hidden behind
paywalls. I believe that contributes to people disregarding them. And it's
sloppy to not highlight changes in a new version of a standard.

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

[Python-ideas] Re: Add builtin function for min(max())

[Bruce Leban]

On Sun, Jul 5, 2020 at 8:57 AM Steven D'Aprano  wrote:

>
> In the absense of any clear winner, my position is that NAN poisoning
> should be opt-in. We should pick the option which inconveniences people
> who want the other the least .
>
> Let's say the stdlib uses Option 1. The function doesn't need to do any
> explicit checks for NANs, so there's no problem with large integers
> overflowing, or Decimals raising ValueError, or any need to do a
> conversion to float.
>
> People who want NAN poisoning can opt-in by doing a check for NANs
> themselves, either in a wrapper function, or by testing the bounds
> *once* ahead of time and then just calling the stdlib `clamp` once they
> know they aren't NANs.


Imagine making the same statement about exceptions:

 Exceptions being raised should be opt-in.


That sounds crazy but it's not. Before exceptions were commonplace, there
were three possibilities when unreasonable operations were performed:

   - return some arbitrary or random value (not a NaN because they hadn't
   been invented);
   - and also set an "error flag" that could be checked by the caller to
   determine if something had gone wrong (but frequently was not);
   - terminate the program.

Things are much better now. Few argue that it was better before. Think of
NaN as the value equivalent of an exception. NaN poisoning is the
equivalent of the fact that any function that doesn't catch an exception
passes it through. I don't usually write code that *uses *NaNs directly. If
I want a distinguished non-numeric value, I use None or some other
sentinel. If a NaN is produced by my code it indicates a bug. NaN poisoning
increases the chance that a NaN generated somewhere won't be hidden by
later code that manipulates that value. Why would I want to suppress that?

Just as an exception can be suppressed by explicit code, Nan poisoning can
be suppressed by explicit checks. So let me rewrite your second and third
paragraphs above (recall Option 1 which you favor is ignore NaNs, and
Option 2 is NaN poisoning):

Let's say the stdlib uses Option 2. The function doesn't need to do any
> explicit checks for NANs, so there's no problem with large integers
> overflowing, or Decimals raising ValueError, causing errors that don't
> get noticed,

or any need to do a conversion to float.
>
> People who don't want NAN poisoning can opt-out by doing a check for NANs
> themselves, either in a wrapper function, or by testing the bounds
> *once* ahead of time and then not calling the stdlib `clamp` once they
> know they are NANs.


This is a better argument. People that use NaNs and expect them write code
to handle it. The rest of us don't want to be surprised by suppressed
errors.

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

[Python-ideas] Re: Incremental step on road to improving situation around iterable strings

[Bruce Leban]

--- Bruce




On Mon, Feb 24, 2020 at 1:19 PM Alex Hall  wrote:

> I think maybe you forgot to reply to the list as well?
>
> I did mean to reply to the list, so adding it back in.


> How many scripts do you have where your own code directly iterated over a
> string? How hard do you think it would be to update that code?
>

Actually quite a bit. I write a lot of code that manipulates words to
create puzzles. In every one of those I use strings as iterables. For what
it's worth, in one of these programs, the problem I encountered was that
strings were not sufficiently performant to solve a very complex problem. I
modeled the strings as integers, and built the subset of needed string-like
operations on them -- including iteration.

If the warning comes from a dependency that hasn't updated, you can simply
> add the appropriate code to filter that category of warnings. I think you
> have the option of two lines of Python code or one environment variable.
>

That's not a good answer IMHO. Warnings should matter. Telling me I can
filter them out means it shouldn't be there in the first place. And I have
to filter them out because warnings that don't matter obscure the ones that
do.


>
> As for your sample, this has been requested twice by others, here was my
> response:
>
> That represents a misunderstanding of my position. I think I'm an outlier
>> among the advocates in this thread, but I do not believe that implementing
>> any of the ideas in this proposal would significantly affect code that
>> lives in the long term. Some code would become slightly better, some
>> slightly worse. My concern surrounds the user experience when debugging
>> code that accidentally iterates over a string. So it's impossible for me to
>> show you code that becomes significantly better because that's not what I'm
>> arguing about, and it's unfair to say that quoting people who have
>> struggled with these bugs is not evidence for the problem.
>>
>
The claim was made by someone that certain code is "problematic" because
the strings are iterable. Asking to see before and after code is certainly
relevant, so we can see exactly what the "problem" is and how it gets
better. Maybe the code gets *worse* and debugging gets easier. That
tradeoff is relevant. And more to the point, is there anything that can't
be done by a better linter instead of mucking up the language?



> Similarly for jdveiga, I cannot give you "real workable surprising code"
>> because I'm talking about code that isn't workable as a result of being
>> surprising. I have given examples of real non-working surprising code, and
>> I can give more, and if that's not indicative of a real problem then I'm
>> very confused and would appreciate more explanation.
>
>
> Now my question is, what is the worst damage that this change could cause?
> Because I haven't heard an argument that goes deeper than aesthetics.
>

The worst damage? The change generates spurious warnings from millions of
lines of correct code. It annoys people to the extent they no longer think
Python is a stable platform to use to build code. Python dies.

Sure that worst case isn't likely but you asked. The bar for changing such
a core feature of Python is much higher than "the worst case isn't going to
kill the language." In my opinion, declaring code deprecated when there is
zero likelihood that it will ever be removed is counter-productive at best.

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

[Python-ideas] Re: Incremental step on road to improving situation around iterable strings

[Bruce Leban]

On Sat, Feb 22, 2020, 5:29 PM Steve Jorgensen  wrote:

> ... Currently, it is necessary to specifically test whether a node is an
> instance of `str` and stop drilling down in that case. One could say that's
> a minor issue, but it's a minor issue that affects a lot of development
> efforts and has do be worked around separately by each developer who
> encounters it. ...
>

Can you show us before and after code so we can gauge how or if this
improves things?

I'm a bit skeptical that it does anything other than replace an instance
check with a different check.

In Java, one of the annoyances (to me) is that strings aren't iterable or
subscriptable. I would fix that if I could, which is the opposite of what
you propose for Python.

--- Bruce

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

[Python-ideas] Re: SQL string prefix idea

[Bruce Leban]

On Fri, Feb 21, 2020 at 5:53 AM  wrote:

> The idea is to add a new string prefix 's' for SQL string. This string
> doesn't do anything in Python, unlike b"" or f"" strings, but interactive
> Python shells like IPython or Jupyter can parse the following characters as
> SQL syntax instead of Python syntax and give SQL syntax highlighting and
> autocompletion, and if they are configured correctly, they can do column
> name autocompletion. Unfortunately when I try to type s"select * from
> table" it gave me syntax error instead, so I think this need to be
> implemented in Python language itself instead of module
>

First, as to SQL specifically, writing literal SQL in code is a bad idea.
It's easy to have bugs, especially sql injection. You should use an ORM at
the very least a SQL builder. Instead of:

sf"select * from sometable where name = '{userName}'"

you would write something like:

sql.query(SomeTable).filter_by(name=userName).all()

And I believe the same thing applies to HTML and just about anything else
that has a complicated enough syntax that this idea would be useful for.

Second, if I had a strong reason to do something like this, I'd want to use
a function that enabled me to add run-time sanity checking (at least during
development and testing phase):

_html_(f"This is a {adverb} bad example.")

and in production that function would just return the value untouched.

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

[Python-ideas] Re: statement-scoped context managers (was: Re: Pickle to/from filename or path)

[Bruce Leban]

On Sat, Feb 8, 2020 at 1:22 PM Chris Angelico  wrote:

> On Sun, Feb 9, 2020 at 8:04 AM Random832  wrote:
> >
> > On Fri, Feb 7, 2020, at 13:03, Todd wrote:
>
> > What if you could write pickle.dump(myobj, with open('myfile.p', 'wb'))?
> >
> > Or other similar examples such as (with open('myfile')).read() - have
> the compiler automatically transform the code into equivalent to wrapping
> the statement in a with block.
> >
>
> Exactly how much code would be wrapped in the 'with' block?
>

This is an intriguing idea, and in the example it's fairly easy to wrap the
entire statement in the with block. It gets a bit more complicated with
short-circuit logic. This is a contrived example to make it easier to read:

result = (with alpha()) and ((with beta()) if (with gamma()) else
(with delta()))


needs to be interpreted something like:

with _alpha := alpha():

if _alpha:

with _gamma:= gamma():

if _gamma:

with _beta := beta():

result = beta

else:

with _delta := delta():

result = delta

else:

result = _alpha


I don't think there's anything surprising there although precisely defining
the semantics will be a little tricky.

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

[Python-ideas] Re: addition of "nameof" operator

[Bruce Leban]

On Mon, Feb 3, 2020 at 3:58 AM Richard Damon 
wrote:

>
> IF Python had a proper refactoring tool (see my other message where I
> question the ability to do that) then the nameof operator would clearly
> help keep logging/debug strings in line with the program definitions.
>
> A statement like print("bar", foo.bar) would be very hard to notice that
> the "bar" match the foo.bar, while
>
> print(nameof(foo.bar), foo.bar) makes the connection explicit.
>

What you're actually asking for is a way for a refactoring tool to
recognize that the string "bar" is a reference to the bar in foo.bar.
You're NOT asking for the Python compiler to recognize that. There are lots
of ways to do this. And Ricky Teachey's examples show that this is pretty
ugly.

On Mon, Feb 3, 2020 at 9:38 AM Ricky Teachey  wrote:

> To restate the motivation: the hope is that there is a potentially large
> benefit of being able to more easily refactor code with something like a
> nameof().
>
> 
>
> class FunctionLogger:
> # NOTE: this docstring will result in a runtime error, so can't even use 
> nameof() here to help ourselves
> f"""Records use of a function.
> The optional `{nameof(FunctionLogger.log)}` parameter is to be a callable 
> that accepts a string.
> It is logging.info by default.
> """
> *...*logging.exception(f"failed to log {func_name!r} call; is 
> {cls_name}.{log_param_name} set correctly?")
>
> *Bottom line: refactoring remains a chore. The win is minimal. Do nothing
> option is preferred.*
>
> Here is a much more readable alternative which has the advantage that it
is already supported by Python. I'm going to show a harder example where I
want to reference foo.bar and allow both foo and bar to be refactored.
Here's the original proposal:

f"The field {nameof(foo)}.{nameof(foo.bar)} can be refactored."

Here's my alternative:

f"""The field {"foo.bar"} can be refactored."""


Since there's no real reason that you'd use {} around a literal string, we
have our refactoring tool recognize that syntax as a variable reference. It
has no net effect on the running code. If we don't want foo to be
refactored, we write instead:

f"""The field foo.{"bar"} can be refactored."""


And if we just want the string to reference "bar" but want to make sure
it's foo.bar not something_else.bar, we could write this:

f"""The field {"foo" and "bar"} can be refactored."""


--- Bruce



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

[Python-ideas] Re: addition of "nameof" operator

[Bruce Leban]

People keep mentioning refactoring. It's a red herring.

No refactoring tool needs a nameof operator added to the language in order
to do its job. And certainly an operator that requires running the program
in order to use it is not going to be helpful. Refactoring tools analyze
the program; they don't run it.

And f-strings are another red herring. There is nothing magical about
expressions inside f-strings compared to those outside.

Ignoring the red herrings, I see no utility in a nameof operator and no way
for it to actually do anything useful.

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

[Python-ideas] Re: Python slicing

[Bruce Leban]

On Thu, Dec 12, 2019, 7:28 AM Siddharth Prajosh  wrote:

> Something like - *s=list(range(100)); s.slice(10, 20).*
>

You mean like say

s[slice(10,20)]

?

Done.

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

[Python-ideas] Fwd: for ... except, with ... except

[Bruce Leban]

And another message that was rejected (I sent from an unregistered email
address)


On Sat, Jul 27, 2019 at 1:49 AM Serhiy Storchaka 
wrote:

> 26.07.19 21:52, Bruce Leban пише:
>
>
> To put this in a simpler way: the proposal is to add an except clause that
> applies ONLY to the direct operation of the with or for statement and not
> to the block. That's an interesting idea.
>
> The one thing I find confusing about your proposal is that the proposed
> syntax does not imply the behavior. In a try statement, the except appears
> at the end and after all possible statements that it could cover. The
> proposal mimics that syntax but with different semantics. Something like
> this would be much more clear what is going on:
>
> for VARIABLE in EXPRESSION:
> except EXCEPTION:
> BLOCK
> BLOCK
>
> with EXPRESSION as VARIABLE:
> except EXCEPTION:
> BLOCK
> BLOCK
>
> while EXPRESSION:
> except EXCEPTION:
> BLOCK
> BLOCK
>
>
> Besides an unusual for Python layout (a clause has different indentation
> than the initial clause of the statement to which it belongs) there is
> other problem. The exception block is not the part of the "for" or "with"
> block. After handling an exception in the "for" clause you do not continue
> to execute the "for" block, but leave the loop. After handling an exception
> in the "with" clause you do not continue to execute the "with" block and do
> not call `__exit__` when leave it. To me, this syntax is much more
> confusing than my initial proposition.
>
And I find it less confusing. And neither of those is the standard to use.
The goal is for syntax to imply semantics (which my proposal does and I do
not think yours does, given several people commenting that they thought it
applied to the entire loop) and to choose syntax that is more clear to more
people (which requires more than two peoples' opinions).

Consider how you would write this if everything was an expression in Python
and we had braces:

for VAR in ( EXPR except EXCEPTION: { BLOCK; break; } ):
BLOCK

I do agree that it is not obvious that the exception block breaks out of
the loop. I think in actual code it will be fairly obvious what's happening
as continuing into the loop when the loop expression through an expression
doesn't make sense. I'm open to alternatives. On the other hand, an except
clause at the bottom of the loop that does not apply to the loop body is
going to catch me every time I see it.

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

[Python-ideas] Fwd: for ... except, with ... except

[Bruce Leban]

I sent this message earlier but it was rejected by the mailer.


On Fri, Jul 26, 2019 at 11:27 AM Serhiy Storchaka 
wrote:

>
> So you will be able to add errors handling like in:
>
>  with connect() as stream:
>  for data in stream:
>  try:
>  write(data)
>  except OSError:
>  handle_write_error()
>  except OSError:
>  handle_read_error()
>  except OSError:
>  handle_connection_error()
>

To put this in a simpler way: the proposal is to add an except clause that
applies ONLY to the direct operation of the with or for statement and not
to the block. That's an interesting idea.

The one thing I find confusing about your proposal is that the proposed
syntax does not imply the behavior. In a try statement, the except appears
at the end and after all possible statements that it could cover. The
proposal mimics that syntax but with different semantics. Something like
this would be much more clear what is going on:

for VARIABLE in EXPRESSION:
except EXCEPTION:
BLOCK
BLOCK

with EXPRESSION as VARIABLE:
except EXCEPTION:
BLOCK
BLOCK

while EXPRESSION:
except EXCEPTION:
BLOCK
BLOCK

or rewriting your example:

with connect() as stream:
except OSError:
handle_connection_error()
for data in stream:
except OSError:
handle_read_error()
try:
write(data)
except OSError:
handle_write_error()
___
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/RTZTO5I4LYCRQXVI3H75RCU4Q4NCPOXT/
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Syntax for allowing extra keys when unpacking a dict as keyword arguments

[Bruce Leban]

On Fri, Apr 12, 2019, 8:12 AM Viktor Roytman 
> >>> func(**{'a': 1, 'b': 2})
> Traceback (most recent call last):
>   File "", line 1, in 
> TypeError: func() got an unexpected keyword argument 'b'
>

Perhaps func(***kws)?

I think this is a real problem given the frequent convention that you can
freely add fields to json objects with the additional fields to be ignored.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] add fluent operator to everything

[Bruce Leban]

On Wed, Feb 20, 2019 at 11:03 AM Rhodri James  wrote:

> On 20/02/2019 18:24, Bruce Leban wrote:
> > a = [1,2,3]
> > (_:=a,_.append(4),_.sort())
>
> I'm not sure what problem you are solving here, but if that's the
> solution I'd rather have the problem.  There is absolutely nothing in
> that syntax that suggests what's going on.
>
>
Given the responses, I think I was a bug more obtuse than necessary. My
apologies.

This is already in Python 3.8. I am NOT actually suggesting a change to the
language. I'm showing how to "solve" the "problem" of wanting to write
chained method calls on a single line. I agree the solution is unreadable
and worse than the problem. Any other proposed solution is merely
bikeshedding the syntax and I think suffers from the same non-readability
problem. For example these are essentially the same:

_:= a  ,_. append(4) ,_. sort()
a :: append(4) :: sort()

--- Bruce
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] add fluent operator to everything

[Bruce Leban]

On Wed, Feb 20, 2019 at 10:34 AM Jonathan Fine  wrote:

> There's a problem with introducing ,_ as a new operator.
>

I should have put "new" in scare quotes to be more clear as it's not really
new. As you've observed this is already implemented. For it to work as in
my example you also need to use the "new" _:= operator which requires
Python 3.8.

--- Bruce
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] add fluent operator to everything

[Bruce Leban]

Here's a syntax that solves this using the new operators _:= and ,_


a = [1,2,3]
(_:=a,_.append(4),_.sort())


Personally, I find this a bit harder to read on one line and would break it
up like this:

(_:=a
,_  .append(4)
,_ ..sort()
)


--- Bruce
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] AMEND PEP-8 TO DISCOURAGE ALL CAPS

[Bruce Leban]

Text in color or against black backgrounds is harder to read than black on
white.
See for example:
https://trevellyan.biz/graphic-design-discussion-how-color-and-contrast-affect-readability-2/

Text where different words in the same sentence are in different colors is
even harder to read.

And I think we should totally ban anyone on the web from putting light gray
text on a lighter gray background
(see https://www.wired.com/2016/10/how-the-web-became-unreadable/ for a
good discussion).

Or to say that another way:
I think we should totally ban anyone on the web from putting light gray
text on a lighter gray background!!

But many of us use editors that use color for syntax highlighting and we do
that because projecting semantics onto the color axis works for us. So we
don't ban colorizing text and we shouldn't.

Capitalizing constants may be slightly harder to read but constants in code
are the minority and emphasizing them is precisely the point.

I'm MINUS_ONE on changing PEP 8. Make your own styleguide if you don't want
to follow PEP 8 in your code.

--- Bruce




On Wed, Jan 30, 2019 at 11:48 AM Abe Dillon  wrote:

> > Is it that really obnoxious?
>
> EXTREMELY!
>
> >  Does using upper case for constants measurably slows down coders? Can
> you cite the actual papers describing such experiments that lead to this
> conclusion ?
>
>
> https://www.mity.com.au/blog/writing-readable-content-and-why-all-caps-is-so-hard-to-read
> https://en.wikipedia.org/wiki/All_caps#Readability
> https://uxmovement.com/content/all-caps-hard-for-users-to-read/
> https://practicaltypography.com/all-caps.html
>
> > from my experience having a visual clue that a value is a constant or an
> enum is something pretty useful.
>
> Do you have any proof that it's useful? Have you ever been tempted to
> modify math.pi or math.e simply because they're lower case? Have you ever
> stopped to wonder if those values change?
>
> If the socket library used packet_host, packet_broadcast, etc. instead of
> PACKET_HOST, PACKET_BROADCAST, ETC. would you be confused about whether
> it's a good idea to rebind those variables? Would you be tempted to write
> the line of code: socket.packet_host = x?
>
> It seems to me that nobody is actually considering what I'm actually
> talking about very carefully. They just assume that because all caps is
> used to convey information that information is actually important. Not just
> important, but important enough that it should be in PEP-8. They say I
> should just violate PEP-8 because it's not strictly enforced. It is
> strictly enforced in workplaces. I don't see why it can't be the other way
> around: PEP-8 doesn't say to use all caps, but if you want to it's OK.
>
> > Surely, I'd hate reading a newspaper article where the editor generously
> sprinkled upper case words everywhere
>
> Exactly. If it's an eye-sore in every other medium, then it seems likely
> to me, the only reason programmers don't consider it an eye-sore is they've
> become inured to it.
>
> > but analogies only go so far, reading code have some similarities with
> reading prose, but still is not the same activity.
>
> CAN you articulate what is DIFFERENT about READING code that makes the ALL
> CAPS STYLE less offensive?
>
> On Tue, Jan 29, 2019 at 6:09 PM Marcos Eliziario <
> marcos.elizia...@gmail.com> wrote:
>
>> Is it that really obnoxious? Does using upper case for constants
>> measurably slows down coders? Can you cite the actual papers describing
>> such experiments that lead to this conclusion ?
>> Because, from my experience having a visual clue that a value is a
>> constant or an enum is something pretty useful.
>> Surely, I'd hate reading a newspaper article where the editor generously
>> sprinkled upper case words everywhere, but analogies only go so far,
>> reading code have some similarities with reading prose, but still is not
>> the same activity.
>>
>> Best,
>> Marcos Eliziario
>>
>>
>>
>> Em ter, 29 de jan de 2019 às 20:30, Cameron Simpson 
>> escreveu:
>>
>>> On 29Jan2019 15:44, Jamesie Pic  wrote:
>>> >On Fri, Jan 4, 2019 at 10:07 PM Bernardo Sulzbach
>>> > wrote:
>>> >> I'd suggest violating PEP-8 instead of trying to change it.
>>> >
>>> >TBH even my bash global environment variables tend to become more and
>>> >more lowercase ...
>>>
>>> If you mean _exported_ variables, then this is actually a really bad
>>> idea.
>>>
>>> The shell (sh, bash, ksh etc) makes no enforcement about naming for
>>> exported vs unexported variables. And the exported namespace ($PATH etc)
>>> is totally open ended, because any programme might expect arbitrary
>>> optional exported names for easy tuning of defaults.
>>>
>>> So, you think, since I only use variables I intend and only export
>>> variables I plan to, I can do what I like. Example script:
>>>
>>>   a=1
>>>   b=2
>>>   export b
>>>
>>> So $b is now exported to subcommands, but not $a.
>>>
>>> However: the "exported set" is initially the environment you inherit.
>>> Which means:

Re: [Python-ideas] Backtick expression: similar to a shorter lambda syntax

[Bruce Leban]

On Wed, Jan 23, 2019 at 1:07 PM James Lu  wrote:

> Backtick expressions (now) use the same scoping and same binding rules as
> other functions.
>

What do you mean by "now"?? There are no backtick expressions in Python
anymore and they were never functions.


> The only difference is that
> class Class:
>   stacticmethod = `...`
>   staticmethod = lambda: ...
>   def instancemethod = `...` # an instancemethod that's called with self
> passed in
>   def property = property(`...`) # an instancemethod that's called with
> self passed in
>

You seem to be inventing new syntax as you go. And you haven't told us how
the first two above differ.


> > The only thing that I can think of is that you want `foo + ^bar` to be
> another way of writing lambda bar: foo + bar with some under-specified 
> behavior
> for evaluating foo and different under-specified behavior for evaluating
> bar.
>
> That is what `lambda bar: foo + ^bar` means.
>

I have no idea what this means. You're giving syntax without semantics. The
word "that" in your sentence is an unbound reference.

>
> A caret in a backtick expression indicates that the name after the caret
> is a parameter. All names with the same name must have a caret before them.
> Mandatory parameters can be passed in as keyword arguments or as positional
> ones.
>

In a word, ick. So to find the parameters for a function, I need to scan
through the entire text of the function looking for ^? And you think that's
an improvement?

You've given no explanation of how this is better and saving typing the
word lambda isn't enough. All in all this sounds like "but these go to 11"
justification and that really is insufficient.

I'm -11.

--- Bruce
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Backtick expression: similar to a shorter lambda syntax

[Bruce Leban]

On Sun, Jan 20, 2019 at 6:43 PM James Lu  wrote:

> Backtick expressions work exactly like lambdas, except that they are bound
> to the instance they are created in every time that class is used to create
> one. To illustrate, ...


First, if there is a useful procedure I am strongly against using backticks
because (1) it's been used in the past with an entirely different meaning
and (2) it looks ugly and is not visually suggestive at all of what it
does, especially not the subtle difference between other function
definitions.

Second, I don't understand exactly what this difference or why it would be
useful. It would help for you to give examples comparing lambda and this
variation.

Third, you mention using ^ in "explicit" expressions to refer to parameters
of the "created function" and I do not know what function you are referring
to or what the exact semantics of this are. Again, a comparison of two
expressions with and without that ^ would help. An expression is not a
function and not all expressions are written inside functions. (And as to
the specific proposed syntax, there already is the ^ xor operator and the
most expected meaning of ^value is ~value. just as the unary + and -
operators corresponds to the binary operators.

The only thing that I can think of is that you want `foo + ^bar` to be
another way of writing lambda bar: foo + bar with some under-specified behavior
for evaluating foo and different under-specified behavior for evaluating bar
.

Finally, if there is some other useful semantics for references inside a
function definition, then I would think the best way to do that is to
implement that, not add a new function difference. For example,

lambda foo: foo + $bar

def sample(foo):

return foo + $foo


where I'm arbitrarily using $ to represent the new semantics whatever they
are (no point in bikeshedding syntax when semantics are yet to be defined).

--- Bruce
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Proposal for an inplace else (?=) operator

[Bruce Leban]

On Saturday, September 22, 2018, Lee Braiden  wrote:

>
> Proposal:
>
> The addition of a ?= operator could provide an elegant solution:
>
> > def teleport(from, to, hitchiker=None, food_accessory=None,
> comfort_accessory=None):
> > hitchhiker ?= Fly()
> > food_accessory ?= Cheeseburger()
> > comfort_accessory ?= Towel()
>
>
> Would be equivalent to (assuming ?= was called __ielse__):
>
> > class ExtendedNone(NoneType)
> > def __ielse__(self, other):
> > return other
> >
> > class ielse_list(list):
> > def __ielse__(self, other):
> > return self
> >
> > None = ExtendedNone()
>
>
This is attacking the workaround not the actual problem. The real problem
is that default parameters are evaluated at function definition time not
call time. Setting the default to None and then replacing it is a
workaround to that problem (and one that doesn't work if None is an
allowable value).

If Python were going to address this problem, I think it better to do
something like:

 def teleport(from, to, hitchiker => Fly(), accessory =>
Towel(hitchhiker)):
 etc.

Where => specifies an expression thst is evaluated inside the function and
Is approximately equivalent to your code except it works even if the caller
passes None. (I don't know what the right syntax for this would be. I just
picked => as something that is suggestive, not legal today and isn't ?= to
avoid confusion with your proposal.)

Note that I shortened your example and modified it slightly to show that I
would have the order of the parameters be significant. The call to Towel
can use the previous hitchiker parameter and it will do what you expect.
Clearly that would work with your code; you just weren't esplicit about it.

My alternative doesn't allow arbitrary None replacement, but I'm not sure
that's a prevalent pattern other than in this case notwithstanding your
examples.

--- Bruce


-- 
--- Bruce
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Keyword only argument on function call

[Bruce Leban]

The proposal is to eliminate the redundancy of writing name=name
repeatedly. But IMHO it doesn't do that consistently. That is it allows
both forms mixed together, e.g.,

f(*, a, b, c=x, d, e)

I believe this is confusing in part because the * need not be near the
arguments it affects. Consider

open(*, name='temp.txt', mode='r', buffering=-1, encoding='utf-8', errors)

By the time you get to the last arg, you'll have forgotten the * at the
beginning. If Python were to adopt a syntax to address this, I think it
should be something like

f(=a, =b, c=x, =d, =e)
open(name='temp.txt', mode='r', buffering=-1, encoding='utf-8', =errors)

Where an = in an argument list without a name in front of it uses the
symbol on the right hand side as the name.

--- Bruce
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Syntactic sugar to declare partial functions

[Bruce Leban]

On Sun, Aug 12, 2018 at 8:31 PM, Abe Dillon  wrote:

>
> [Steven D'Aprano]
>
>> ...if we aren't even willing to move out of our own comfort zone to
>> the extent of learning accurate jargon terms from our own profession?
>
>
> Very few of us are computer scientists by profession. That's not even
> where 'lambda' comes from. In computer science, it's called an "anonymous
> function". "lambda" comes from lambda calculus.
>

Lambda calculus IS computer science. Rejecting lambda as CS is as bad as
rejecting the + operator because that's mathematics. I can legitimately
argue that + in Python is not the + in mathematics because the Python
mathematical operators operate on integers and floats, not real numbers.
Therefore we should use a different word like "floatadd". Of course not.

Lambda calculus is a model of computation. It was invented about 30 years
before the name "computer science" but is nonetheless foundational computer
science. If using lambda as a keyword leads people to go and learn about
lambda calculus that is a good thing.

And as to saying a lambda function is an "anonymous function": the
anonymity is not a property of the function. If I assign it to a name, it's
no longer anonymous. Really a "lambda" or "lambda function" is just a
function, but "lambda" is a synecdoche for "function created with a lambda
expression".

--- Bruce
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] a sorting protocol dunder method?

[Bruce Leban]

On Sun, Dec 3, 2017 at 3:06 PM, Chris Barker  wrote:

>
> However, if you are writing a custom class ... 
>
> But what if there was a sort key magic method:
>
>  __key__ or __sort_key__ (or whatever)
>
> that would be called by the sorting functions 
>
> It seems this would provide a easy way to make custom classes sortable
> that would be nicer for end users (not writing key functions), and possibly
> more performant in the "usual" case.
>

On Sun, Dec 3, 2017 at 4:57 PM, Steven D'Aprano  wrote:

>
> This shows the problem with putting the key function into the data type.
> What if I want to sort AttrDicts by their list of keys instead? Or their
> (key, value) pairs? What is so special about sorting by ID (which may
> not even exist!) that it deserves to be part of the AttrDict itself?


I think you're arguing against this for the wrong reason. Chris was talking
about custom classes having the *option* of making them sortable by
providing a key method in the class definition. This strikes me as useful
and I can imagine having used this if it were available. What you're saying
is that there are classes which probably shouldn't define a __sort_key__
function, which I quite agree with. But I don't think it's a good argument
against this proposal.


On Sun, Dec 3, 2017 at 3:06 PM, Chris Barker  wrote:

> Am I imagining the performance benefits?
>

Maybe. Looking strictly at O(-) cost, there's no difference between a key
function and comparison operators. Sure it might potentially only make O(n)
calls to the key function and O(n log n) calls to compare the keys vs. O(n
log n) calls to the comparator functions but that might not actually be
faster. There certainly are cases where implementing a key function would
be quite slow.

--- Bruce
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Allow additional separator character in variables

[Bruce Leban]

On Sun, Nov 19, 2017 at 4:18 PM, Mikhail V  wrote:

> Bruce Leban wrote:
>
> > It is not a misfortune or even true that Python uses hyphen for minus.
> > The name of the character used in Python is HYPHEN-MINUS.
>
> This is pure demagogy, name it HYPHEN-MINUS-TINYDASH if you like,
> but what aspect of reality does it change apart of its name?
>

You've gone from making a bad suggestion to trolling.

While you may *think* this character is a hyphen, you're simply wrong. When
ASCII was created it was a 7-bit character set limited to 94 printable
characters plus space and 33 control characters. The designers explicitly
added a single double-duty character for both hyphen and minus, just as
they added a single character for single and double quotes rather than left
and right quotes. Were they mimicking the typewriter? Maybe they were
following the example of Hollerith code which only had uppercase. It
doesn't matter. It's not that they were unaware of the different uses or
the existence of typographic quotes. Just as monospace fonts were not
created because people didn't know about variable width fonts. It is what
it is. And pretending other people are idiots is inappropriate.

You can use accent grave as a left quote and apostrophe as a right quote if
you want to, but if you insist that Python is living in the dark ages
because it doesn't do things *your way* then you're just being rude.

... render
> hyphen as *hyphen*, which is well established for centuries in typography,
> and defined as a dash of 50% width of the letter "o" and is aligned to
> lowercase.
> As well as the Minus glyph which is defined as ca. 110% of "o" width
> and is aligned


False. There is no standard going back centuries defining the widths of the
different kinds of dashes. For that matter, there is no standard *today*
for what letters and symbols look like. See Doug Hofstadter's great paper
on this https://web.stanford.edu/group/SHR/4-2/text/hofstadter.html or the
Unicode consortium list of emoji
https://unicode.org/emoji/charts/full-emoji-list.html for great examples of
the non-standard nature of typography. Heck almost all vendors put cheese
on the *hamburger* emoji when obviously it only belongs on the cheeseburger
emoji. And Google puts the cheese below the meat which is clearly wrong as
the international standard for cheeseburgers puts the cheese on the top.

Just take some Python sources and count the amount of underscores
> and minus operators. This will give you an image of how important
> separators are compared to minus operator.
>

A non sequitur. Count the number of instances of the letter Z in English
vs. the letter E which tells you that Z is unimportant. So let's get rid of
it. Of course that may piss off the Polish people since it's the 9th most
frequent letter (4.9%) in Polish. While this makes a great story -- see
"Meihem In Ce Klasrum" http://www.tau.ac.il/~pauzner/funs/simpler.html --
but not a great reality.

That said, no one has argued that a word separator in names is a bad idea
and we have two choices: capitalizingEachWord and
underscores_between_words. These work well enough that the idea of breaking
every single Python program that uses subtraction just because one person
believes we are being antediluvian -- without any evidence -- is just not
going to happen. (Ooh. See what I did there. I typed two hyphen-minus
characters to get an "em dash" and you probably didn't even notice that I
was breaking centuries of tradition that the only proper way to write an em
dash is with a single piece of metal type.)

If you want to make serious contributions to Python or any other project
you need to understand why this is a bad idea.


>
> > I am extremely skeptical that a legitimate usability study would
> > find that record-count is better than record_count.
>
> Oh come on, probably you also want study for emoticons as a separators?
>

Yes, if someone insisted that emoticons were superior to underscores as
separators and implied I was an idiot for not agreeing with that.

--- Bruce
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Allow additional separator character in variables

[Bruce Leban]

On Sat, Nov 18, 2017 at 8:44 PM, Mikhail V  wrote:
>
>
> That seems to be another showcase of misfotune that Python
> uses hyphen for minus operator. I know it is not language designer's
> fault, because basic ASCII simply did not not include minus character.
> But do you realise that the **current** problem you are adressing is that
> font designers forgot to make the minus character (in monospaced font)
> distinctive from the hyphen character?


It is not a misfortune or even true that Python uses hyphen for minus.
The name of the character used in Python is HYPHEN-MINUS.
http://unicode.org/cldr/utility/character.jsp?a=002D
It is both a hyphen and a minus. And it served double-duty even in ASCII.

A language that requires using characters not present on standard keyboards
is unlikely to be successful.
Or we would all be programming in APL.

And it's not as if no one every thought of this before. Maybe you've heard
of COBOL?


>
>
> Would hyphens in variable names improve readability sometimes?
>
> For reading code, indeed, always and very much.


No it wouldn't. You're personal preference is hardly authoritative. I am
extremely skeptical that a legitimate usability study would find that
record-count is better than record_count.

There are studies that monospace fonts are harder to read than
proportionally spaced, e.g.,
http://journals.sagepub.com/doi/pdf/10.1177/001872088302500303. Yet many
programmers use monospace fonts because the advantages -- in our opinions
-- outweigh the disadvantages. And the reality is that only my opinion
matters when I'm choosing the fonts to display my code in, not yours.

You-know-what-really-would-increase-readability?
Allowing-the-use-of-spaces-in-variable-names.
As-you-can-see-from-this-example-hyphens-between-words-decreases-readability.

And because spaces between words is mostly not valid syntax currently, this
change would be easier to introduce than breaking every single program out
there by re-purposing hyphen-minus. But I'm not seriously proposing this
because I think the modest benefits are outweighed by the many problems it
would introduce.

--- Bruce
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Remote package/module imports through HTTP/S

[Bruce Leban]

On Wed, Aug 23, 2017 at 11:11 AM, Chris Angelico  wrote:

>
>
> If you read his README, it's pretty explicit about URLs; the risk is
> that "https://github.com/someuser/somelib"; can be intercepted, not
> that "someuser" is malicious. If you're worried about the latter,
> don't use httpimport.


I don't see the word "security" or "risk" in the readme. The risk is not
just that someuser is malicious but the risk that they, their github
credentials or their code have been compromised.

The reason that if this feature were to be implemented, I would want it
outside the source code (command line option) is that that puts the control
in the hands of the person running the code. This is appropriate for the
stated scenarios. There's no possibility of a hidden live github dependency.

--- Bruce
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Remote package/module imports through HTTP/S

[Bruce Leban]

On Wed, Aug 23, 2017 at 10:37 AM, John Torakis 
wrote:

>
> Github can be trusted 100% percent for example.


This isn't even remotely close to true. While I'd agree with the statement
that the SSL cert on github is reasonably trustworthy, the *content* on
github is NOT trustworthy and that's where the security risk is.

I agree that this is a useful feature and there is no way it should be on
by default. The right way IMHO to do this is to have a command line option
something like this:

python --http-import somelib=https://github.com/someuser/somelib


which then redefines the import somelib command to import from that source.
Along with your scenario, it allows people, for example, to replace a
library with a different version without modifying source or installing a
different version. That's pretty useful.

--- Bruce
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Add pathlib.Path.write_json and pathlib.Path.read_json

[Bruce Leban]

I'm not in favor of this idea for the reason mentioned by many of the other
posters. BUT ... this does bring up something missing from json readers: *the
ability to read one json object from the input rather than reading the
entire input* and attempting to interpret it as one object. For my use
case, it would be sufficient to read whole lines only but I can imagine
other use cases.

The basic rule would be to read as much of the input as necessary (and no
more) to read a single json object, ignoring leading white space.

In practical terms:

   - if the first character is [ or { or " read to the matching ] or } or "
   - otherwise if the first character is a digit or '-' read as many
   characters as possible to parse a number
   - otherwise attempt to match 'true', 'false' or 'null'
   - otherwise fail


--- Bruce
Check out my puzzle book and get it free here:
http://J.mp/ingToConclusionsFree (available on iOS)



On Mon, Mar 27, 2017 at 5:50 AM, Ram Rachum  wrote:

> Hi guys,
>
> What do you think about adding methods pathlib.Path.write_json and
> pathlib.Path.read_json , similar to write_text, write_bytes, read_text,
> read_bytes?
>
> This would make writing / reading JSON to a file a one liner instead of a
> two-line with clause.
>
>
> Thanks,
> Ram.
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Fwd: Null coalescing operator

[Bruce Leban]

On Sat, Sep 10, 2016 at 6:02 PM, David Mertz  wrote:

> What I was getting at with "essentially" was that it would *do the same
> thing* that an AttributeError does.  That is, if `x.foo` can't be evaluated
> (i.e. x doesn't have an attribute 'foo'), then access is informally "an
> error."  The hypothetical "x?.foo" catches that "error" and substitutes a
> different value.  The particular implementation under-the-hood is less
> important for most programmers who might use the construct (and I think
> documentation would actually give an informal equivalent as something
> similar to what I put in the NoneCoalesce class).
>

That's not a good way to think about it. This new operator is only checking
for None and not actually checking for AttributeErrors. Consider:

(3).x# AttributeError
{}.x # AttributeError

None.x   # AttributeError


(3)?.x   # still AttributeError

{}?.x# still AttributeError

None?.x  # None


And also:

None.__class__   # 

None?.__class__  # None


And it's certainly not the case that those values don't accept any
attributes:

(3).real# 3
{}.values   # 
None.__class__  #

--- Bruce
Check out my puzzle book and get it free here:
http://J.mp/ingToConclusionsFree (available on iOS)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] real numbers with SI scale factors

[Bruce Leban]

On Sun, Aug 28, 2016 at 6:44 PM, Ken Kundert 
wrote:

> When working with a general purpose programming language, the above numbers
> become:
>
> 780kpc -> 7.8e+05
> 108MPa -> 1.08e+08
> 600TW  -> 6e+14
> 3.2Gb  -> 3.2e+09
> 53pm   -> 5.3e-11
> $8G-> 8e+09
>

These are not equal. 780kpc is a *number with units*. 7.8e+05 == 78 is
a *unitless number*. All the numbers on the right hand side above have no
units so I can't tell which are pc or W or m or $. It's asking for trouble
to go halfway in representing units. On the left hand side, 780kpc + 108MPa
is invalid while 780kpc + 53pm is valid. On the right hand side, sums of
any two numbers are valid as they would be with the unitless SI prefixes.

So if you want to solve this problem, write a module that supports units.
For example,  m(780, 'kpc') == m('780kpc') == m(780, kpc)  and it's legal
to write  m(780, kpc) + m(53, pm)  but an exception gets raised if you
write  m(2, kW) + m(3, kh)  instead of  m(2, kW) * m(3, km) == m(6, MWh).
In fact, several people have already done that. Here are three I found in <
1 minute of searching:

https://pint.readthedocs.io/en/0.7.2/
https://pypi.python.org/pypi/units/
https://python-measurement.readthedocs.io/en/latest/

Should support for this ever get added to the core language? I doubt it.
But if one of these modules becomes enormously popular and semi-standard,
you never know. I think you're much more likely to get this into your
Python code by way of a preprocessor.

--- Bruce
Check out my puzzle book and get it free here:
http://J.mp/ingToConclusionsFree (available on iOS)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] A proposal to rename the term "duck typing"

[Bruce Leban]

On Sunday, August 28, 2016, ROGER GRAYDON CHRISTMAN  wrote:

>
> We have a term in our lexicon "duck typing" that traces its origins, in
> part to a quote along the lines of
> "If it walks like a duck, and talks like a duck, ..."
>
> ...
>
> In that case, it would be far more appropriate for use to call this sort
> of type analysis "witch typing"
>

I believe the duck is out of the bag on this one. First the "duck test"
that you quote above is over 100 years old.
https://en.m.wikipedia.org/wiki/Duck_test So that's entrenched.

Second this isn't a Python-only term anymore and language is notoriously
hard to change prescriptively.

Third I think the duck test is more appropriate than the witch test which
involves the testers faking the results.

--- Bruce



-- 
--- Bruce
Check out my puzzle book and get it free here:
http://J.mp/ingToConclusionsFree (available on iOS)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/