Re: [Python-ideas] Python reviewed

[Steven D'Aprano]

On Tue, Jan 10, 2017 at 09:44:31AM +0800, Simon Lovell wrote:
> Also in Python you can use:
> 
> for x in range (1,j+1):
> 
> to loop j times. Although it does read as though it is looping j+1 times 
> to those not familiar.

*shrug*

To those "not familiar", most language features are mysterious and it is 
easy to guess wrong.

What's the difference between foo[x+1] and foo(x+1)? 

In Python, the first is a key or index lookup and the second is a 
function call; but in Mathematica, the first is a function call and the 
second is foo multiplied by x+1.

Python prides itself in having a much easier learning curve than many 
languages, with syntax that is close to "executable pseudo-code", but 
that doesn't mean that there is *nothing* to learn.

 
> One more comment I wanted to make about end blocks,
[...]


If I never have to see code like:

end
end
end
end
end
end

again, it will be too soon.

 
> I still struggle to see why it should be 
> mandatory though? For those who prefer to have the block closing 
> delimiters this way, is the need for a keyword (could be a command line 
> option) really the objection?

It's not mandatory -- there are dozens of other languages you can use 
that will satisfy your urge for a redundant "end" block marker.

But for *Python*, it is mandatory because it is Guido's language, not 
yours. When you design your own language, you can design it to be as 
complicated or simple, as baroque or plain as you like.

Think about what you are asking for: a command-line option that controls 
whether or not the interpreter requires "end" after each block. Now 
every single library module needs to be written twice, once with "end", 
once without. Otherwise, it won't even compile for half the users.

If all you care about is something physically at the end of the block, 
without the compiler enforcing it, then Python already supports this, 
using your choice of keyword:

with open(filename) as f:
for line in f:
if condition:
while something:
spam(line)
#end
#finish
#done
#conclusion

Problem solved.



-- 
Steve
___
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] Python Reviewed

[Rob Cliffe]

On 10/01/2017 05:18, Simon Lovell wrote:

Hi Kyle,

I don't see the harm caused from having a do-while construct. Not the 
most used construct but it is sometimes useful and not having it means 
you need to either have a first time through marker or a break at the 
end of a "while True:" loop.



I would say that None should also be non-boolean. Otherwise you are 
saying that things which might be None would be True if not None.



Re: SQLAlchemy, this does not resolve the issues satisfactorily to me.


Re: half-loop. The idea that you have the same code before entry and 
at the end of the loop is really ugly and raises the potential for 
errors. I can remember doing something similarly ugly with this for 
looping through a cursor but I can't recall why I couldn't just do a 
.fetchall() and then loop through the results. Maybe I ultimately 
changed it to do precisely that. Perhaps you have too big a data set 
to load into memory all at once though and can't do it that way. 
Anyway, the SQL processing is all too difficult in Python and Java and 
nearly all modern languages.



Re: Conditional expression. You could have: " = if  
then  else requires more concentration than it should. However, this means 
another keyword*.


* General comment: I posted this because Googling didn't give me a 
satisfactory answer to why Python is the way that it is. I think I see 
it now. Guido hates keywords.

That last sentence is a ridiculous (and insulting) statement.
Adding a keyword to Python means that all Python code ever written 
potentially becomes incompatible with the next Python release (if it 
might use that keyword as an identifier).

So the bar for adding a *new* keyword is necessarily very high.
I don't find this particularly logical but it is what it is and it 
also isn't going to change. That seems also to explain the else 
keyword at the end of the while loop.



Anyway, I think this discussion has reached its natural conclusion here.

Rob Cliffe


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

[Python-ideas] How to respond to trolling

[Guido van Rossum]

Was it really necessary for all the usual folks on this list to engage with
the "Python review" threads? I think a much more effective response would
have been a resounding silence.

-- 
--Guido van Rossum (python.org/~guido)
___
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] Python Reviewed

[Ryan Gonzalez]

I just want to point ONE thing out:


On Jan 9, 2017 11:18 PM, "Simon Lovell"  wrote:

* General comment: I posted this because Googling didn't give me a
satisfactory answer to why Python is the way that it is. I think I see it
now. Guido hates keywords. I don't find this particularly logical but it is
what it is and it also isn't going to change. That seems also to explain
the else keyword at the end of the while loop.


No, it's because every new keyword that you add has the potential to break
code that uses that as a variable name. Python is used by thousands of
places across the globe right now. It would be suicidal to break half of
that because someone felt the need for a new keyword.

I feel like there are two things you're missing:

1. The stark majority of the "review" you made is taking about stuff that
simply isn't going to change. Again, too much code to break.

2. The entirety of the "review" is your opinion. You may love the `end`
keyword and enjoy using it (for some reason), but that doesn't mean it's
*objectively* better. It just means it's better for you. Python is the way
it is because that's the way it is, and we like it that way.


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



--
Ryan (ライアン)
Yoko Shimomura > ryo (supercell/EGOIST) > Hiroyuki Sawano >> everyone else
http://kirbyfan64.github.io/
___
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] How to respond to trolling

[Ivan Levkivskyi]

On 10 January 2017 at 16:29, Guido van Rossum  wrote:

> I think a much more effective response would have been a resounding
> silence.
>

I agree.

--
Ivan
___
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] How to respond to trolling

[Ned Batchelder]

On 1/10/17 10:43 AM, Ivan Levkivskyi wrote:
> On 10 January 2017 at 16:29, Guido van Rossum  > wrote:
>
> I think a much more effective response would have been a
> resounding silence.
>
>
> I agree.
>

I don't like to use the term "trolling" except for people who are trying
to annoy people.  I think the recent thread was misguided, but not
malicious.  I do agree that the thread should have ended at "unless you
are seriously proposing a change to the language, this is not the right
list."

--Ned.

___
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] api suggestions for the cProfile module

[Thane Brimhall]

I hate to be "that guy" but... bump!

Does anyone have thoughts on this topic? I assume the silence is because 
this suggestion is too trivial to matter.

/Thane

On Tuesday, December 20, 2016 at 5:51:49 PM UTC-7, Thane Brimhall wrote:
>
> I use cProfile a lot, and would like to suggest three backwards-compatible 
> improvements to the API.
>
> 1: When using cProfile on a specific piece of code I often use the 
> enable() and disable() methods. It occurred to me that this would be an 
> obvious place to use a context manager.
>
> 2: Enhance the `print_stats` method on Profile to accept more options 
> currently available only through the pstats.Stats class. For example, 
> strip_dirs could be a boolean argument, and limit could accept an int. This 
> would reduce the number of cases you'd need to use the more complex API.
>
> 3: I often forget which string keys are available for sorting. It would be 
> nice to add an enum for these so a user could have their linter and IDE 
> check that value pre-runtime. Since it would subclass `str` and `Enum` it 
> would still work with all currently existing code.
>
> The current documentation contains the following code:
>
> import cProfile, pstats, io
> pr = cProfile.Profile()
> pr.enable()
> # ... do something ...
> pr.disable()
> s = io.StringIO()
> sortby = 'cumulative'
> ps = pstats.Stats(pr, stream=s).sort_stats(sortby)
> ps.print_stats()
> print(s.getvalue())
>
> While the code below doesn't exactly match the functionality above (eg. 
> not using StringIO), I envision the context manager working like this, 
> along with some adjustments on how to get the stats from the profiler:
>
> import cProfile, pstats
> with cProfile.Profile() as pr:
> # ... do something ...
> pr.print_stats(sort=pstats.Sort.cumulative, limit=10, strip_dirs=True)
>
> As you can see, the code is shorter and somewhat more self-documenting. 
> The best thing about these suggestions is that as far as I can tell they 
> would be backwards-compatible API additions.
>
> What do you think? Thank you in advance for your time!
>
> /Thane
>
___
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] api suggestions for the cProfile module

[Ethan Furman]

On 01/10/2017 08:36 AM, Thane Brimhall wrote:


Does anyone have thoughts on this topic? I assume the silence is because
 this suggestion is too trivial to matter.


Sometimes it's just a matter of timing.  :)


I use cProfile a lot, and would like to suggest three backwards-compatible
 improvements to the API.

1: When using cProfile on a specific piece of code I often use the
 enable() and disable() methods. It occurred to me that this would
 be an obvious place to use a context manager.


Absolutely.


2: Enhance the `print_stats` method on Profile to accept more options
 currently available only through the pstats.Stats class. For example,
 strip_dirs could be a boolean argument, and limit could accept an int.
 This would reduce the number of cases you'd need to use the more complex
 API.


I don't have much experience with cProfile, but this seems reasonable.


3: I often forget which string keys are available for sorting. It would
 be nice to add an enum for these so a user could have their linter and
 IDE check that value pre-runtime. Since it would subclass `str` and
 `Enum` it would still work with all currently existing code.


Absolutely!  :)


The current documentation contains the following code:

import cProfile, pstats, io
pr = cProfile.Profile()
pr.enable()
# ... do something ...
pr.disable()
s = io.StringIO()
sortby = 'cumulative'
ps = pstats.Stats(pr, stream=s).sort_stats(sortby)
ps.print_stats()
print(s.getvalue())

While the code below doesn't exactly match the functionality above (eg. not
 using StringIO), I envision the context manager working like this, along
 with some adjustments on how to get the stats from the profiler:

import cProfile, pstats
with cProfile.Profile() as pr:
 # ... do something ...
 pr.print_stats(sort=pstats.Sort.cumulative, limit=10, strip_dirs=True)

As you can see, the code is shorter and somewhat more self-documenting. The
 best thing about these suggestions is that as far as I can tell they would
 be backwards-compatible API additions.


The `pr.print_stats... line should not be inside the `with` block unless you 
want to profile that part as well.

These suggestions seem fairly uncontroversial.  Have you opened an issue on the 
issue tracker?

The fun part of the patch will be the C code, but a Python proof-of-concept 
would be useful.

--
~Ethan~
___
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] api suggestions for the cProfile module

[Gregory P. Smith]

At a glance, all of these sound like good modernizing enhancements for
cprofile. It just takes someone to contribute the work. :)

On Tue, Jan 10, 2017, 8:57 AM Ethan Furman  wrote:

> On 01/10/2017 08:36 AM, Thane Brimhall wrote:
>
> > Does anyone have thoughts on this topic? I assume the silence is because
> >  this suggestion is too trivial to matter.
>
> Sometimes it's just a matter of timing.  :)
>
> > I use cProfile a lot, and would like to suggest three
> backwards-compatible
> >  improvements to the API.
> >
> > 1: When using cProfile on a specific piece of code I often use the
> >  enable() and disable() methods. It occurred to me that this would
> >  be an obvious place to use a context manager.
>
> Absolutely.
>
> > 2: Enhance the `print_stats` method on Profile to accept more options
> >  currently available only through the pstats.Stats class. For example,
> >  strip_dirs could be a boolean argument, and limit could accept an int.
> >  This would reduce the number of cases you'd need to use the more complex
> >  API.
>
> I don't have much experience with cProfile, but this seems reasonable.
>
> > 3: I often forget which string keys are available for sorting. It would
> >  be nice to add an enum for these so a user could have their linter and
> >  IDE check that value pre-runtime. Since it would subclass `str` and
> >  `Enum` it would still work with all currently existing code.
>
> Absolutely!  :)
>
> > The current documentation contains the following code:
> >
> > import cProfile, pstats, io
> > pr = cProfile.Profile()
> > pr.enable()
> > # ... do something ...
> > pr.disable()
> > s = io.StringIO()
> > sortby = 'cumulative'
> > ps = pstats.Stats(pr, stream=s).sort_stats(sortby)
> > ps.print_stats()
> > print(s.getvalue())
> >
> > While the code below doesn't exactly match the functionality above (eg.
> not
> >  using StringIO), I envision the context manager working like this, along
> >  with some adjustments on how to get the stats from the profiler:
> >
> > import cProfile, pstats
> > with cProfile.Profile() as pr:
> >  # ... do something ...
> >  pr.print_stats(sort=pstats.Sort.cumulative, limit=10,
> strip_dirs=True)
> >
> > As you can see, the code is shorter and somewhat more self-documenting.
> The
> >  best thing about these suggestions is that as far as I can tell they
> would
> >  be backwards-compatible API additions.
>
> The `pr.print_stats... line should not be inside the `with` block unless
> you want to profile that part as well.
>
> These suggestions seem fairly uncontroversial.  Have you opened an issue
> on the issue tracker?
>
> The fun part of the patch will be the C code, but a Python
> proof-of-concept would be useful.
>
> --
> ~Ethan~
> ___
> 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] api suggestions for the cProfile module

[Thane Brimhall]

Thanks for getting back to me on this! Yes timing can be a big factor. :) 
Turns out this gave me opportunity to look a little further back in the 
archives and someone suggested a very similar API change in November, so 
maybe more people than just me would want a feature like this.

Good call on putting the print_stats outside of the context block. Kinda 
meta to profile the profiler...

If the next step is to open an issue on the tracker, I'll do that. I can 
work on a Python proof-of-concept to attach there as well.

Again, thanks for your feedback!

/Thane

On Tuesday, January 10, 2017 at 9:57:54 AM UTC-7, Ethan Furman wrote:
>
> On 01/10/2017 08:36 AM, Thane Brimhall wrote: 
>
> > Does anyone have thoughts on this topic? I assume the silence is because 
> >  this suggestion is too trivial to matter. 
>
> Sometimes it's just a matter of timing.  :) 
>
> > I use cProfile a lot, and would like to suggest three 
> backwards-compatible 
> >  improvements to the API. 
> > 
> > 1: When using cProfile on a specific piece of code I often use the 
> >  enable() and disable() methods. It occurred to me that this would 
> >  be an obvious place to use a context manager. 
>
> Absolutely. 
>
> > 2: Enhance the `print_stats` method on Profile to accept more options 
> >  currently available only through the pstats.Stats class. For example, 
> >  strip_dirs could be a boolean argument, and limit could accept an int. 
> >  This would reduce the number of cases you'd need to use the more 
> complex 
> >  API. 
>
> I don't have much experience with cProfile, but this seems reasonable. 
>
> > 3: I often forget which string keys are available for sorting. It would 
> >  be nice to add an enum for these so a user could have their linter and 
> >  IDE check that value pre-runtime. Since it would subclass `str` and 
> >  `Enum` it would still work with all currently existing code. 
>
> Absolutely!  :) 
>
> > The current documentation contains the following code: 
> > 
> > import cProfile, pstats, io 
> > pr = cProfile.Profile() 
> > pr.enable() 
> > # ... do something ... 
> > pr.disable() 
> > s = io.StringIO() 
> > sortby = 'cumulative' 
> > ps = pstats.Stats(pr, stream=s).sort_stats(sortby) 
> > ps.print_stats() 
> > print(s.getvalue()) 
> > 
> > While the code below doesn't exactly match the functionality above (eg. 
> not 
> >  using StringIO), I envision the context manager working like this, 
> along 
> >  with some adjustments on how to get the stats from the profiler: 
> > 
> > import cProfile, pstats 
> > with cProfile.Profile() as pr: 
> >  # ... do something ... 
> >  pr.print_stats(sort=pstats.Sort.cumulative, limit=10, 
> strip_dirs=True) 
> > 
> > As you can see, the code is shorter and somewhat more self-documenting. 
> The 
> >  best thing about these suggestions is that as far as I can tell they 
> would 
> >  be backwards-compatible API additions. 
>
> The `pr.print_stats... line should not be inside the `with` block unless 
> you want to profile that part as well. 
>
> These suggestions seem fairly uncontroversial.  Have you opened an issue 
> on the issue tracker? 
>
> The fun part of the patch will be the C code, but a Python 
> proof-of-concept would be useful. 
>
> -- 
> ~Ethan~ 
> ___ 
> Python-ideas mailing list 
> python...@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/

[Python-ideas] api suggestions for the cProfile module

[Jelle Zijlstra]

2017-01-10 8:57 GMT-08:00 Ethan Furman :

> On 01/10/2017 08:36 AM, Thane Brimhall wrote:
>
> Does anyone have thoughts on this topic? I assume the silence is because
>>  this suggestion is too trivial to matter.
>>
>
> Sometimes it's just a matter of timing.  :)
>
> I use cProfile a lot, and would like to suggest three backwards-compatible
>>  improvements to the API.
>>
>> 1: When using cProfile on a specific piece of code I often use the
>>  enable() and disable() methods. It occurred to me that this would
>>  be an obvious place to use a context manager.
>>
>
> Absolutely.
>
> 2: Enhance the `print_stats` method on Profile to accept more options
>>  currently available only through the pstats.Stats class. For example,
>>  strip_dirs could be a boolean argument, and limit could accept an int.
>>  This would reduce the number of cases you'd need to use the more complex
>>  API.
>>
>
> I don't have much experience with cProfile, but this seems reasonable.
>
> 3: I often forget which string keys are available for sorting. It would
>>  be nice to add an enum for these so a user could have their linter and
>>  IDE check that value pre-runtime. Since it would subclass `str` and
>>  `Enum` it would still work with all currently existing code.
>>
>
> Absolutely!  :)
>
> The current documentation contains the following code:
>>
>> import cProfile, pstats, io
>> pr = cProfile.Profile()
>> pr.enable()
>> # ... do something ...
>> pr.disable()
>> s = io.StringIO()
>> sortby = 'cumulative'
>> ps = pstats.Stats(pr, stream=s).sort_stats(sortby)
>> ps.print_stats()
>> print(s.getvalue())
>>
>> While the code below doesn't exactly match the functionality above (eg.
>> not
>>  using StringIO), I envision the context manager working like this, along
>>  with some adjustments on how to get the stats from the profiler:
>>
>> import cProfile, pstats
>> with cProfile.Profile() as pr:
>>  # ... do something ...
>>  pr.print_stats(sort=pstats.Sort.cumulative, limit=10,
>> strip_dirs=True)
>>
>> As you can see, the code is shorter and somewhat more self-documenting.
>> The
>>  best thing about these suggestions is that as far as I can tell they
>> would
>>  be backwards-compatible API additions.
>>
>
> The `pr.print_stats... line should not be inside the `with` block unless
> you want to profile that part as well.
>
> These suggestions seem fairly uncontroversial.  Have you opened an issue
> on the issue tracker?
>
> The fun part of the patch will be the C code, but a Python
> proof-of-concept would be useful.
>
> These changes may not even require C code, since (contrary to its name)
cProfile actually is implemented partly in Python. For example, the context
manager change could be made simply by adding __enter__ and __exit__ to the
cProfile.Profile class.

> --
> ~Ethan~
> ___
> 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] api suggestions for the cProfile module

[Thane Brimhall]

That is great news because I'd be happy to do the implementation myself if 
it only requires Python. (Sadly I'm not proficient in C.) I'll be coding 
over the next couple days preparing an example implementation, then I will 
open an issue on the bug tracker.

/Thane

On Tuesday, January 10, 2017 at 12:19:14 PM UTC-7, Jelle Zijlstra wrote:
>
>
> 2017-01-10 8:57 GMT-08:00 Ethan Furman >:
>
>> On 01/10/2017 08:36 AM, Thane Brimhall wrote:
>>
>> Does anyone have thoughts on this topic? I assume the silence is because
>>>  this suggestion is too trivial to matter.
>>>
>>
>> Sometimes it's just a matter of timing.  :)
>>
>> I use cProfile a lot, and would like to suggest three backwards-compatible
>>>  improvements to the API.
>>>
>>> 1: When using cProfile on a specific piece of code I often use the
>>>  enable() and disable() methods. It occurred to me that this would
>>>  be an obvious place to use a context manager.
>>>
>>
>> Absolutely.
>>
>> 2: Enhance the `print_stats` method on Profile to accept more options
>>>  currently available only through the pstats.Stats class. For example,
>>>  strip_dirs could be a boolean argument, and limit could accept an int.
>>>  This would reduce the number of cases you'd need to use the more complex
>>>  API.
>>>
>>
>> I don't have much experience with cProfile, but this seems reasonable.
>>
>> 3: I often forget which string keys are available for sorting. It would
>>>  be nice to add an enum for these so a user could have their linter and
>>>  IDE check that value pre-runtime. Since it would subclass `str` and
>>>  `Enum` it would still work with all currently existing code.
>>>
>>
>> Absolutely!  :)
>>
>> The current documentation contains the following code:
>>>
>>> import cProfile, pstats, io
>>> pr = cProfile.Profile()
>>> pr.enable()
>>> # ... do something ...
>>> pr.disable()
>>> s = io.StringIO()
>>> sortby = 'cumulative'
>>> ps = pstats.Stats(pr, stream=s).sort_stats(sortby)
>>> ps.print_stats()
>>> print(s.getvalue())
>>>
>>> While the code below doesn't exactly match the functionality above (eg. 
>>> not
>>>  using StringIO), I envision the context manager working like this, along
>>>  with some adjustments on how to get the stats from the profiler:
>>>
>>> import cProfile, pstats
>>> with cProfile.Profile() as pr:
>>>  # ... do something ...
>>>  pr.print_stats(sort=pstats.Sort.cumulative, limit=10, 
>>> strip_dirs=True)
>>>
>>> As you can see, the code is shorter and somewhat more self-documenting. 
>>> The
>>>  best thing about these suggestions is that as far as I can tell they 
>>> would
>>>  be backwards-compatible API additions.
>>>
>>
>> The `pr.print_stats... line should not be inside the `with` block unless 
>> you want to profile that part as well.
>>
>> These suggestions seem fairly uncontroversial.  Have you opened an issue 
>> on the issue tracker?
>>
>> The fun part of the patch will be the C code, but a Python 
>> proof-of-concept would be useful.
>>
>> These changes may not even require C code, since (contrary to its name) 
> cProfile actually is implemented partly in Python. For example, the context 
> manager change could be made simply by adding __enter__ and __exit__ to the 
> cProfile.Profile class.
>
>> --
>> ~Ethan~
>> ___
>> Python-ideas mailing list
>> python...@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] How to respond to trolling

[Nick Timkovich]

If you're proposing throwing half of Python's current syntax in the bin,
this isn't the right list either.

If not marginally malicious, I think it's delusional to think a post to
Language X's lists by someone who recommends multiple breaking changes
would ever be accepted. The correct response (if any) would be to use
another language or write your own transpiler that better agrees with your
aesthetic.

Nick

>
I don't like to use the term "trolling" except for people who are trying to
> annoy people.  I think the recent thread was misguided, but not malicious.
> I do agree that the thread should have ended at "unless you are seriously
> proposing a change to the language, this is not the right list."
>
>
> --Ned
>
___
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] How to respond to trolling

[Guido van Rossum]

Whether the intent was to annoy or just to provoke, the effect was dozens
of messages with people falling over each other trying to engage the OP,
who clearly was ignorant of most language design issues and uninterested in
learning, and threw some insults in for good measure. The respondents
should have known better.

-- 
--Guido van Rossum (python.org/~guido)
___
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] api suggestions for the cProfile module

[Terry Reedy]

On 1/10/2017 11:36 AM, Thane Brimhall wrote:

Does anyone have thoughts on this topic? I assume the silence is because
this suggestion is too trivial to matter.


1 and 3 don't really need discussion here.  2 perhaps.  I would open 3 
separate enhancement issues.  As near as I can tell, profile and 
cProfile have the same API and to the extent it is true, this should be 
maintained.



On Tuesday, December 20, 2016 at 5:51:49 PM UTC-7, Thane Brimhall wrote:

I use cProfile a lot, and would like to suggest three
backwards-compatible improvements to the API.

1: When using cProfile on a specific piece of code I often use the
enable() and disable() methods. It occurred to me that this would be
an obvious place to use a context manager.

2: Enhance the `print_stats` method on Profile to accept more
options currently available only through the pstats.Stats class. For
example, strip_dirs could be a boolean argument, and limit could
accept an int. This would reduce the number of cases you'd need to
use the more complex API.

3: I often forget which string keys are available for sorting. It
would be nice to add an enum for these so a user could have their
linter and IDE check that value pre-runtime. Since it would subclass
`str` and `Enum` it would still work with all currently existing code.


--
Terry Jan Reedy

___
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] How to respond to trolling

[Ryan Birmingham]

I think that replying with an almost canned response, like the one Ned
proposed ("unless you are seriously proposing a change to the language,
this is not the right list."), would help discourage other list members
from responding where responses aren't necessary.

-Ryan Birmingham

On 10 January 2017 at 16:58, Guido van Rossum  wrote:

> Whether the intent was to annoy or just to provoke, the effect was dozens
> of messages with people falling over each other trying to engage the OP,
> who clearly was ignorant of most language design issues and uninterested in
> learning, and threw some insults in for good measure. The respondents
> should have known better.
>
> --
> --Guido van Rossum (python.org/~guido)
>
> ___
> 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] How to respond to trolling

[Steven D'Aprano]

On Tue, Jan 10, 2017 at 07:29:12AM -0800, Guido van Rossum wrote:
> Was it really necessary for all the usual folks on this list to engage with
> the "Python review" threads? I think a much more effective response would
> have been a resounding silence.

Giving a newcomer the Silent Treatment because they've questioned some 
undocumented set of features not open to change is not Open, Considerate 
or Respectful (the CoC). Even if their ideas are ignorant or ill-thought 
out, we must give them the benefit of the doubt and assume they are 
making their comments in good faith rather than trolling.

Shunning is a particularly nasty form of passive-aggression, as the 
person being shunned doesn't even get any hint as to what they have done 
to bring it on. It's one thing to ignore an unrepentant troublemaker or 
troll after numerous warnings -- that's the old Usenet "plonk" or 
kill-file treatment -- but greeting a newcome who has inadvertently (we 
must assume good faith) crossed a line in that way is hostile behaviour.

I don't think it is necessary for somebody to explicitly say the magic 
words "I propose this as a change..." for it to be obvious that the OP 
was suggesting his "review" to initiate a discussion for ways Python 
should change.

I don't know whether the OP has learned anything from his treatment 
here. But I know he wouldn't learn anything except that the Python 
community is closed-minded and unwelcoming if he had been greeted with 
silence.


-- 
Steve
___
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] PEP 540: Add a new UTF-8 mode

[Chris Barker - NOAA Federal]

>> How common is this problem?
>
> Last 2 or 3 years, I don't recall having be bitten by such issue.

We just got bitten by this on our CI server. Granted, we could fix it
by properly configuring docker, but it would have been nice if it "
just worked"

-CHB
___
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] How to respond to trolling

[Pavol Lisy]

On 1/11/17, Steven D'Aprano  wrote:
> On Tue, Jan 10, 2017 at 07:29:12AM -0800, Guido van Rossum wrote:
>> Was it really necessary for all the usual folks on this list to engage
>> with
>> the "Python review" threads? I think a much more effective response would
>> have been a resounding silence.
>
> Giving a newcomer the Silent Treatment because they've questioned some
> undocumented set of features not open to change is not Open, Considerate
> or Respectful (the CoC). Even if their ideas are ignorant or ill-thought
> out, we must give them the benefit of the doubt and assume they are
> making their comments in good faith rather than trolling.

I think that in this case:

not all(people) == any(people)

So in my humble opinion it is good to say something by some (which
reflect CoC culture of python community) and be silent like zen master
(and most people did it) by others :)

BTW. This discussion could be inspiring and we could prepare PEP where
we could give some hints how to do (stupid?) things in unified and
clever way! ;)
For example:

1. if you want to have endblocks then use "# endfor" instead of "# for"

2. if you want to replace "self" by one letters then use  ᐠ (CANADIAN
SYLLABICS FINAL GRAVE) see
https://www.dcl.hpi.uni-potsdam.de/home/loewis/table-3131.html

etc.

Some editors could probably syntax highlight these constructs (and
maybe hide dot too in case of replacing self :P) in future (at least
in fancy mode :)

(
Some of us could test idea through vi conceal feature

for example to http://gnosis.cx/bin/.vim/after/syntax/python.vim
insert something like
syntax match pyNiceStatement "\https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] How to respond to trolling

[Stephen J. Turnbull]

Steven D'Aprano writes:

 > Giving a newcomer the Silent Treatment because they've questioned some 
 > undocumented set of features not open to change is not Open, Considerate 
 > or Respectful (the CoC). Even if their ideas are ignorant or ill-thought 
 > out, we must give them the benefit of the doubt and assume they are 
 > making their comments in good faith rather than trolling.

Honest question: do you think that response has to be done in public?

(Whether Guido intended "private" as an alternative or not is a red
herring, irrelevant to my question.)

I would prefer answers at GitHub:
https://github.com/python/overload-sig/issues/5.

but that's up to respondents.  (Will summarize responses privately and
in other channels to that issue.  This is an experiment for the Overload
SIG: https://mail.python.org/mm3/mailman3/lists/overload-...@python.org/.)

Steve
___
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] PEP 540: Add a new UTF-8 mode

[Stephen J. Turnbull]

Chris Barker - NOAA Federal writes:
 > >> How common is this problem?
 > >
 > > Last 2 or 3 years, I don't recall having be bitten by such issue.
 > 
 > We just got bitten by this on our CI server. Granted, we could fix it
 > by properly configuring docker, but it would have been nice if it "
 > just worked"

Of course.  The question is not "should cb@noaa properly configure
docker?", it's "Can docker properly configure docker (soon enough)?
And if not, should we configure Python?"  The third question depends
on whether fixing it for you breaks things for others.
___
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] PEP 540: Add a new UTF-8 mode

[INADA Naoki]

>
> Of course.  The question is not "should cb@noaa properly configure
> docker?", it's "Can docker properly configure docker (soon enough)?
> And if not, should we configure Python?"  The third question depends
> on whether fixing it for you breaks things for others.

When talking about general Docker image, using C locale is OK for most cases.
In other words, images using C locale is properly configured.
All of node.js, Ruby, Perl, Go and Rust application can talk UTF-8 in docker
using C locale, without special configuration.
Locale dependent application is very special in this area.
___
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] PEP 540: Add a new UTF-8 mode

[Stephen J. Turnbull]

INADA Naoki writes:

 > When talking about general Docker image, using C locale is OK for
 > most cases.  In other words, images using C locale is properly
 > configured.

s/properly/compatibly/.  "Proper" has strong connotations of
"according to protocol".  Configuring LC_CTYPE for ASCII expecting
applications to say "You're lying!" and spew UTF-8 anyway is not
"proper".

That kind of thing makes me very nervous, and I think justifiably so.
And it's only *sufficient* to justify a change to Python's defaults if
Python checks for and accurately identifies when it's in a container.

Anyway, I need to look more carefully at the actual PEPs and see if
there's something concrete to worry about.  But remember, we have
about 18 months to chew over this if necessary -- I'm only asking for
a few more days (until after the "cripple the minds of Japanese youth
day", er, "University Admissions Center Examination" this weekend ;-).

Steve
___
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] PEP 540: Add a new UTF-8 mode

[INADA Naoki]

>
> That kind of thing makes me very nervous, and I think justifiably so.
> And it's only *sufficient* to justify a change to Python's defaults if
> Python checks for and accurately identifies when it's in a container.
>

In my company, we use network boot servers.
To reduce boot image, the image is built with minimalistic approach too.
So there were only C locale in most of our servers, and many
people in my company had bitten by this problem.

I teach them to adding `export PYTHONIOENCODING=utf-8` in their
.bashrc.  But they had bitten again when using cron.

So this problem is not only for docker container.
Since UTF-8 dominated, many people including me use C locale
to avoid unintentional behavior of commands seeing locale (sort,
ls, date, bash, etc...).

And use non C locale only for reading non English output from some
command, like `man` or `hg help`.  It's for i18n / l10n, but not for
changing encoding.

People live in UTF-8 world are never helped by changing encoding by locale.
They are only bitten by the behavior.

> Anyway, I need to look more carefully at the actual PEPs and see if
> there's something concrete to worry about.  But remember, we have
> about 18 months to chew over this if necessary -- I'm only asking for
> a few more days (until after the "cripple the minds of Japanese youth
> day", er, "University Admissions Center Examination" this weekend ;-).
>
> Steve

Off course.  And both PEP doesn't propose default behavior except C locale.
So there are 36+ months about changing default behavior.
I hope 36 months is enough for people using legacy systems are moving to
UTF-8 world.

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