[Python-ideas] Re: Allow star unpacking within an slice expression

[Serhiy Storchaka]

06.03.20 18:30, Neil Girdhar пише:
Reviving this old thread since this is hitting me again today.  Is there 
any momentum on extending tuple unpacking to within slices?


It does not supported by AST. But with issue34822 changes it could be 
implemented.


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

[Python-ideas] Re: New explicit methods to trim strings

[Ethan Furman]

On 03/06/2020 04:03 PM, Steven D'Aprano wrote:

On Thu, Mar 05, 2020 at 12:45:28PM -0800, Andrew Barnert via Python-ideas wrote:



Well, I like the idea if someone can come up with a good naming
scheme—something that at least reminds me which function is the “set
of chars” stripper and which the “substring” stripper,


You've been a Python programmer for how many years now? Do you currently
have trouble remembering what lstrip and rstrip do?


Speaking for myself, about 13 years.  And, yes, I do occasionally forget that 
the strips are character based.  I can easily imagine it's worse for polyglot 
programmers.



We already have `[l|r]strip` methods. If we want to associate the new
methods with those, I suggest

 strip_prefix
 strip_suffix


Works for me.  Easy to add to bytes, too, if somebody is so inclined.

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

[Python-ideas] Re: New explicit methods to trim strings

[Guido van Rossum]

On Fri, Mar 6, 2020 at 5:46 PM Christopher Barker 
wrote:

>
> (Since bytes may be used for file names I think they should get this new
> capability too.)
>
> I don’t really care one way or another, but is it really still the case
> that bytes need to be used for filenames? For uses other than just passing
> them around?
>

Yes, Linux in particular does not guarantee that file names are using any
particular encoding (let alone a consistent encoding for different files).
The only two bytes that are special are '\0' and '/'.


> Sigh.
>

Indeed, especially since macOS *does* guarantee that filenames are Unicode
(even using a specific normalization) and Windows represents filenames
internally as UTF-16, IIRC.


> In any case, while it’s fine to consider the bytes issue in choosing a
> name, I hope it doesn’t derail the whole idea.
>

I didn't like the name stripstr anyway. :-)


> -CHB
>
>>
>
>
>> On Fri, Mar 6, 2020 at 16:10 Steven D'Aprano  wrote:
>>
>>> On Fri, Mar 06, 2020 at 03:33:49PM -0800, Ethan Furman wrote:
>>>
>>> > I think we should have a `stripstr()` as an alias for strip, and a new
>>> > `stripchr()`.
>>>
>>> Shouldn't they be the other way around?
>>>
>>> `strip` removes chars from a set of chars; the proposed method will
>>> remove a prefix/suffix.
>>>
>>>
>>> > And I'm perfectly okay with bytes() not having those methods.  ;-)
>>>
>>> If heavy users of bytes want these methods, they can request them
>>> separately. There's no backwards compatibility requirement for new
>>> string methods to be automatically added to bytes.
>>>
>>> I guess the question now is do we need a PEP?
>>>
>>
-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

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

[Python-ideas] Re: New explicit methods to trim strings

[Christopher Barker]

(Since bytes may be used for file names I think they should get this new
capability too.)

I don’t really care one way or another, but is it really still the case
that bytes need to be used for filenames? For uses other than just passing
them around?

Sigh.

In any case, while it’s fine to consider the bytes issue in choosing a
name, I hope it doesn’t derail the whole idea.

-CHB

>


> On Fri, Mar 6, 2020 at 16:10 Steven D'Aprano  wrote:
>
>> On Fri, Mar 06, 2020 at 03:33:49PM -0800, Ethan Furman wrote:
>>
>> > I think we should have a `stripstr()` as an alias for strip, and a new
>> > `stripchr()`.
>>
>> Shouldn't they be the other way around?
>>
>> `strip` removes chars from a set of chars; the proposed method will
>> remove a prefix/suffix.
>>
>>
>> > And I'm perfectly okay with bytes() not having those methods.  ;-)
>>
>> If heavy users of bytes want these methods, they can request them
>> separately. There's no backwards compatibility requirement for new
>> string methods to be automatically added to bytes.
>>
>> I guess the question now is do we need a PEP?
>>
>>
>> --
>> Steven
>> ___
>> Python-ideas mailing list -- python-ideas@python.org
>> To unsubscribe send an email to python-ideas-le...@python.org
>> https://mail.python.org/mailman3/lists/python-ideas.python.org/
>> Message archived at
>> https://mail.python.org/archives/list/python-ideas@python.org/message/I2PNEQFRKMBZNOBB4BNXEAASFPQ4727F/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
> --
> --Guido (mobile)
> ___
> 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/SMB6AIVBEFPR447YCD363EQAPIWJ4D34/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-- 
Christopher Barker, PhD

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
___
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/MMDJWJ4BZ4ZEX7WOZUEFYTC3JTEWTUU6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: New explicit methods to trim strings

[Ethan Furman]

On 03/06/2020 04:07 PM, Steven D'Aprano wrote:

On Fri, Mar 06, 2020 at 03:33:49PM -0800, Ethan Furman wrote:



I think we should have a `stripstr()` as an alias for strip, and a new
`stripchr()`.


Shouldn't they be the other way around?

`strip` removes chars from a set of chars; the proposed method will
remove a prefix/suffix.


Um, yeah.  Thanks for catching that.

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

[Python-ideas] Re: New explicit methods to trim strings

[Guido van Rossum]

This will only need a PEP if the eventual proposal is controversial. :-)

Someone (Andrew Barnert?) has claimed that another name, like cut or trim,
would be too confusing. I’m not sure I agree. I think strip_prefix is more
confusing, and stripstr or strstrip would unnecessarily cut off the option
of adding this to bytes. (Since bytes may be used for file names I think
they should get this new capability too.)

On Fri, Mar 6, 2020 at 16:10 Steven D'Aprano  wrote:

> On Fri, Mar 06, 2020 at 03:33:49PM -0800, Ethan Furman wrote:
>
> > I think we should have a `stripstr()` as an alias for strip, and a new
> > `stripchr()`.
>
> Shouldn't they be the other way around?
>
> `strip` removes chars from a set of chars; the proposed method will
> remove a prefix/suffix.
>
>
> > And I'm perfectly okay with bytes() not having those methods.  ;-)
>
> If heavy users of bytes want these methods, they can request them
> separately. There's no backwards compatibility requirement for new
> string methods to be automatically added to bytes.
>
> I guess the question now is do we need a PEP?
>
>
> --
> Steven
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/I2PNEQFRKMBZNOBB4BNXEAASFPQ4727F/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-- 
--Guido (mobile)
___
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/SMB6AIVBEFPR447YCD363EQAPIWJ4D34/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: New explicit methods to trim strings

[Steven D'Aprano]

On Fri, Mar 06, 2020 at 03:33:49PM -0800, Ethan Furman wrote:

> I think we should have a `stripstr()` as an alias for strip, and a new 
> `stripchr()`.

Shouldn't they be the other way around?

`strip` removes chars from a set of chars; the proposed method will 
remove a prefix/suffix.


> And I'm perfectly okay with bytes() not having those methods.  ;-)

If heavy users of bytes want these methods, they can request them 
separately. There's no backwards compatibility requirement for new 
string methods to be automatically added to bytes.

I guess the question now is do we need a PEP?


-- 
Steven
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/I2PNEQFRKMBZNOBB4BNXEAASFPQ4727F/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: New explicit methods to trim strings

[Steven D'Aprano]

On Thu, Mar 05, 2020 at 12:45:28PM -0800, Andrew Barnert via Python-ideas wrote:

> Well, I like the idea if someone can come up with a good naming 
> scheme—something that at least reminds me which function is the “set 
> of chars” stripper and which the “substring” stripper,

You've been a Python programmer for how many years now? Do you currently 
have trouble remembering what lstrip and rstrip do? If not, I doubt you 
will suddenly forget their meaning because we add a pair of new methods 
with quite different names.

Unless, of course, we go down the path of a foolish consistency and 
choose names which are too similar:

lcut
lremove
ldelete

in which case you are right, people would certainly confuse the two. So 
let's not do that :-)

This proposal isn't for a generic "substring" stripper. We already have 
that, it is called str.replace. This proposal is specifically for 
removing *prefixes and suffixes* not arbitrary substrings.

Referencing the words "prefix" and "suffix" is not "gratuitously" adding 
"yet another way to say l/left/start" but a critical part of the 
methods' semantics. If we were to describe what the proposed methods do, 
we surely would say something like these:

cut the prefix
delete the prefix
remove the prefix
strip the prefix
trim the prefix

because that is what the method does: it cuts/deletes etc the *prefix*, 
not some arbitrary substring or set of characters. But we wouldn't say:

cut the substring on the left

because "on the left" is not sufficient. How far on the left? Can the 
substring be anywhere in the left half of the string?

"The red peppers are very red and fresh".cut_left_substring("red")
=> "The peppers are very red and fresh"

I hope that we can agree that some names are simply too long and 
cumbersome:

str.cut_substring_all_the_way_on_left(prefix)

We already have `[l|r]strip` methods. If we want to associate the new 
methods with those, I suggest

strip_prefix
strip_suffix

which will show up right next to `strip` in the docs and state 
explicitly what they do. (Personally, I prefer to add a little more 
conceptual distance by calling the method "cut_" but I'm willing to 
accept "strip" if others like it.)

I trust that is clear enough. If not, what else could "strip prefix" 
mean, if not strip the prefix?

Contrast:

lstrip_string

"Yes, I know it operates on a string, it's a string method after all. 
But what does it do?"



The following is a tangential note about some Python history, and isn't 
really relevant to the proposal as such. So you can stop reading here 
without missing anything important.



[Christopher]
> > 1) I don’t think any other string methods take keywords.

[Andrew]
> Sure, but they mostly go back to the days before keyword arguments 
> existed at all, much less now when they can be implemented relatively 
> easily even in C functions.

Keywords predate string methods.

String methods were only added in Python 2.0:

https://docs.python.org/2.0/lib/string-methods.html

In Python 1.5, strings had no methods:

>>> 'a'.upper()
Traceback (innermost last):
  File "", line 1, in ?
AttributeError: 'string' object has no attribute 'upper'

and we used the "string" module functions. I don't see any builtins with 
keyword arguments in Python 1.5:

https://docs.python.org/release/1.5/lib/node26.html

but pure Python functions certainly had them. Since string functions 
were originally written in Python, they could have had keyword 
arguments had they been desired.


-- 
Steven
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/K4REZUP24TUGZZ5P5KMG3KRR5DFTMWQ4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: New explicit methods to trim strings

[Ethan Furman]

On 03/06/2020 02:59 PM, Guido van Rossum wrote:

On Fri, Mar 6, 2020 at 2:19 PM Steven D'Aprano wrote:



Can we just fix this?

Obviously there will be a month of bike-shedding arguments about the
names *wink* but can we at least agree that this is a genuine source of
confusion and a useful addition to the string API?


Yes.


Excellent.

I think we should have a `stripstr()` as an alias for strip, and a new 
`stripchr()`.

And I'm perfectly okay with bytes() not having those methods.  ;-)

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

[Python-ideas] Re: New explicit methods to trim strings

[Guido van Rossum]

Yes.

On Fri, Mar 6, 2020 at 2:19 PM Steven D'Aprano  wrote:

> Can we just fix this? The lack of an obvious way to delete a prefix or
> suffix is a continual pain point for users of the language. We've just
> had yet another bug report from some poor user who misunderstood the
> lstrip method:
>
> https://bugs.python.org/issue39880
>
> More examples:
>
> https://bugs.python.org/issue37114
> https://bugs.python.org/issue36410
> https://bugs.python.org/issue32772
> https://bugs.python.org/issue25979
>
> https://stackoverflow.com/questions/4148974/is-this-a-bug-in-python-2-7
>
> https://stackoverflow.com/questions/34544247/understanding-pythons-lstrip-method-on-strings
>
> Obviously there will be a month of bike-shedding arguments about the
> names *wink* but can we at least agree that this is a genuine source of
> confusion and a useful addition to the string API?
>
>
>
> --
> Steven
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/GRGAFIII3AX22K3N3KT7RB4DPBY3LPVG/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

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

[Python-ideas] Re: New explicit methods to trim strings

[Steven D'Aprano]

Can we just fix this? The lack of an obvious way to delete a prefix or 
suffix is a continual pain point for users of the language. We've just 
had yet another bug report from some poor user who misunderstood the 
lstrip method:

https://bugs.python.org/issue39880

More examples:

https://bugs.python.org/issue37114
https://bugs.python.org/issue36410
https://bugs.python.org/issue32772
https://bugs.python.org/issue25979

https://stackoverflow.com/questions/4148974/is-this-a-bug-in-python-2-7
https://stackoverflow.com/questions/34544247/understanding-pythons-lstrip-method-on-strings

Obviously there will be a month of bike-shedding arguments about the 
names *wink* but can we at least agree that this is a genuine source of 
confusion and a useful addition to the string API?



-- 
Steven
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/GRGAFIII3AX22K3N3KT7RB4DPBY3LPVG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: More descriptive error message than "too many values to unpack"

[Matthias Bussonnier]

>
>
> In general Python error messages don't include the relevant values or much 
> information about them, although I often wish they would. For example when I 
> get a KeyError I wish I could see which keys are present, unless there's too 
> many for it to be practical. I'm speculating, but I think there are two main 
> reasons for this:
>
> 1. To avoid executing arbitrary __repr__ methods.
> 2. To avoid the performance cost of creating a message for an exception that 
> may be caught and thrown away.
>
> Neither of these really apply to int('45f').
>
> Are there any other major reasons for the general lack of information? It 
> feels like an intentional decision beyond implementation difficulty. I 
> imagine we can work around both reasons:
>
> 1. There's a lot of information that can be extracted and displayed without 
> running any user defined code.
> 2. Objects can be saved (such as the dict that raised KeyError) while 
> deferring the message rendering until it's requested.


Yes there is, IPython used to display values of local frame variables
by default, though some of these values for some users were secrets
that ended up in logs files.
So even base types are sensitive and I don't think we should print
them by default.

Well you say what about interactive sessions ? Surely it's fine !

...Unless you are doing a demo at a conference and you end up printing
your AWS key in a live broadcast...

Though I'm definitively for having more informations displayed, even
if some of that is opt-in. With rich reprs in Jupyter we could
actually show variable values on hover with the mouse, or in a
collapsible html element.
-- 
Matthias
___
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/HUJ6NSC5ISTIST3ND6FBGXEUHU5VLVYX/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Allow star unpacking within an slice expression

[Neil Girdhar]

Reviving this old thread since this is hitting me again today.  Is there 
any momentum on extending tuple unpacking to within slices?


On Thursday, December 21, 2017 at 4:33:07 PM UTC-5, Neil Girdhar wrote:
>
> I didn't think of this when we were discussing 448.  I ran into this 
> today, so I agree with you that it would be nice to have this.
>
> Best,
>
> Neil
>
> On Monday, December 4, 2017 at 1:02:09 AM UTC-5, Eric Wieser wrote:
>>
>> Hi,
>>
>> I've been thinking about the * unpacking operator while writing some 
>> numpy code. PEP 448 allows the following:
>>
>>values = 1, *some_tuple, 2
>>object[(1, *some_tuple, 2)]
>>
>> It seems reasonable to me that it should be extended to allow
>>
>>item = object[1, *some_tuple, 2]
>>item = object[1, *some_tuple, :]
>>
>> Was this overlooked in the original proposal, or deliberately rejected?
>>
>> Eric
>>
>___
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/3737BQS7QFRLGE5CHQQNL3DVLLIMYH6R/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: More descriptive error message than "too many values to unpack"

[Neil Girdhar]

I also would prefer richer exceptions especially if it can be done without 
introducing any other problems.

In the same vein, I once suggested a richer inheritance failure message 
(this, basically: https://github.com/NeilGirdhar/inheritance_graph), for 
which if I remember correctly Guido was mildly supportive.  I didn't have 
time to make a proposal patch.

On Monday, March 2, 2020 at 4:32:35 PM UTC-5, Sebastian Kreft wrote:
>
> There was a proposal (by me) some time ago to add some structured 
> information to some of the Exceptions. See 
> https://www.python.org/dev/peps/pep-0473/, but it finally got rejected 
> due to being too broad. I'd be happy to revive (parts of) the proposal if 
> anyone is interested.
>
> I managed though to create a PR adding a name attribute to NameError, see 
> https://github.com/python/cpython/pull/6271 and 
> https://bugs.python.org/issue37797.
>
> On Mon, Mar 2, 2020 at 6:01 PM Alex Hall > 
> wrote:
>
>>
>>
>> On Mon, Mar 2, 2020 at 12:47 AM Christopher Barker > > wrote:
>>
>>> That being said, more information is better than less, so maybe an 
>>> unpacking error should show the *value* of what was being unpacked:
>>>
>>> >>> a, b = 1, 2, 3
>>> Traceback (most recent call last):
>>>   File "", line 1, in 
>>> ValueError: too many values to unpack (expected 2)
>>>
>>> Which, in fact, is what iPython already does:
>>>
>>> In [5]: a,b = 1,2,3 
>>>
>>>
>>> ---
>>> ValueErrorTraceback (most recent call 
>>> last)
>>>  in 
>>> > 1 a,b = 1,2,3
>>>
>>> ValueError: too many values to unpack (expected 2)
>>>
>>
>> The only extra thing IPython is doing here is showing the source line, 
>> which it can do because it saves the input in linecache. The standard shell 
>> never saves its input so it never shows in tracebacks. I do think that's an 
>> issue, but if you ran these examples in files you'd get the same amount of 
>> information either way.
>>
>> (cause it's showing the line of code, not the run time values)
>>>
>>
>> There are many tools which enhance tracebacks with local variables. Even 
>> the standard traceback module can do it. But of course improving the 
>> default experience with just the right amount of information would be 
>> ideal. 
>>  
>>
>>> So if possible, it would be great if error messages did generally show 
>>> the value(s) of the objects involved, if possible.
>>>
>>> Then that would be:
>>>
>>> ValueError: too many values to unpack (expected 2, got : 'this')
>>>
>>> Given that it's a ValueError, it seem the *value* should be known, and 
>>> generally relevant.
>>>
>>> And this is already done for some ValueErrors:
>>>
>>> In [3]: i = int('45f')   
>>>
>>>
>>> ---
>>> ValueErrorTraceback (most recent call 
>>> last)
>>>  in 
>>> > 1 i = int('45f')
>>>
>>> ValueError: invalid literal for int() with base 10: '45f'
>>>
>>> Maybe it should be for ALL Value Errors? 
>>>
>>
>> In general Python error messages don't include the relevant values or 
>> much information about them, although I often wish they would. For example 
>> when I get a KeyError I wish I could see which keys are present, unless 
>> there's too many for it to be practical. I'm speculating, but I think there 
>> are two main reasons for this:
>>
>> 1. To avoid executing arbitrary __repr__ methods.
>> 2. To avoid the performance cost of creating a message for an exception 
>> that may be caught and thrown away.
>>
>> Neither of these really apply to int('45f').
>>
>> Are there any other major reasons for the general lack of information? It 
>> feels like an intentional decision beyond implementation difficulty. I 
>> imagine we can work around both reasons:
>>
>> 1. There's a lot of information that can be extracted and displayed 
>> without running any user defined code.
>> 2. Objects can be saved (such as the dict that raised KeyError) while 
>> deferring the message rendering until it's requested.
>> ___
>> Python-ideas mailing list -- python...@python.org 
>> To unsubscribe send an email to python-id...@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/SLIFGO4FSMAM4AMZZX3B4Y3YQCNZACPE/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
>
> -- 
> Sebastian Kreft
>
___
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 

[Python-ideas] Re: CSV Dictwriter - Handling escape characters

[Guido van Rossum]

EVERYONE, please don’t follow up on the meta discussion. What’s said is
said. But this type of discussion never leads to anything useful, and often
causes more bad blood. (Chris, next time I think it would be better if you
sat on your hands. And ditto for everyone else who thinks to respond to an
issue about tone.)

On Thu, Mar 5, 2020 at 23:44 Chris Angelico  wrote:

> On Fri, Mar 6, 2020 at 6:22 PM Aleksi Matikainen
>  wrote:
> > And in the end, I ended up transforming the strings, using str.replace
> as you and the comments in Stack Overflow suggested. It worked great!
> > It is also a good point that I should explain in detail why a module
> should be changed, I will definitely think about that later first if I run
> into another problem.
> >
>
> In other words, what Andrew suggested was, in fact, the solution you went
> with.
>
> > I'm still a bit surprised at the negative tone in your reply. [chomp
> lots of passive-aggressive chuff]
> > (N.B. I have also seen this kind of negative reply culture before in the
> whole Stack Overflow community, which makes me a bit sad. Is it because
> many programmers are engineers? I have noticed this kind of behavior in the
> engineering student / tech community too: always looking for answers for
> every problem, always thinking their own solution is the best one, no
> matter what the situation, often forgetting the manners or that we all are
> humans, after all, and some are just learning new things out of curiosity.
> I'm an engineer/former tech student myself.)
> >
>
> By "negative tone", do you mean that you were given advice that
> involved something other than what you specifically asked for help
> with? You had a problem, and your proposed solution was to *change a
> programming language* to suit your purposes. Instead, you were given
> an extremely workable method - which you ended up using - for solving
> the problem by writing code. Which is exactly what programmers do.
>
> http://www.catb.org/esr/faqs/smart-questions.html#goal
>
> When you start out by requesting a specific step, rather than your
> ultimate goal, you have to be prepared for people to offer solutions
> that achieve the goal by some other means. (Sometimes those solutions
> won't actually work. But you can always respond saying "yes, that
> would work, except that X Y and Z".)
>
> > I hope you will think about what I wrote in the third paragraph. You
> will have much more success if you shape your answers in a positive and
> constructive way and leave negative things behind. I have observed this in
> every learning situation I have been in and the best results have been in
> the positive communities where I get positive and constructive feedback.
> >
>
> Define "success". What would Andrew succeed at better? Remember, he
> isn't being paid to solve your problems in your preferred way. What he
> offered you was a perfectly valid solution to your problem, and
> ultimately, he isn't paid to do that either, so "success" isn't really
> the best term to use even for that. But let's suppose that success is
> defined as "getting a response from the OP saying that the problem was
> solved". If that's the case, then this thread is a success for both
> Andrew and Rhodri, since both posts were making the same
> recommendation (although Rhodri didn't go into much detail).
>
> Perhaps, before you jump to the conclusion that people are being
> "negative", you should reconsider how you are judging those responses.
> Focus less on whether someone gave you the precise solution you hoped
> they'd magic up, and more on whether your actual problem was solved.
>
> ChrisA
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/5XJVTIYDXWCMFQPJ2GQJK6SLZFM4B63P/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-- 
--Guido (mobile)
___
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/BIVXUGNFZ4FJ3TAND3NLOLWSY3DSLXIF/
Code of Conduct: http://python.org/psf/codeofconduct/