A Short Survey To Understand Practitioner' Perspectives Towards The Requirements Engineering

[ETEM ÇETİN TOPTANİ]

Dear Sir or Madam,


We prepared a short survey to understand practitioners’ perspectives
towards the requirements engineering. Our survey basically aims to clarify
on many aspects of the requirements engineering applied in industry, including
(i) requirements gathering and specifications, (ii) requirements
modifications, (iii) requirements analysis, and (iv) requirements
transformation. The survey results will be submitted to a reputable journal
on software engineering.


The survey takes about 2-5 minutes to participate, we would be so grateful
if you could separate your time. Also, please circulate the email to anyone
who may be interested.


The survey link: https://forms.gle/DhLqr15GXVhJhzzy6


All the best,

 Etem Çetin Toptani

-- 
*Bu mesajı yazdırmadan önce çevreye verebileceğiniz zararları bir kez daha 
düşününüz. *
*Think of the environment once more before printing out this 
message.*

-- 
*Bu mesajı yazdırmadan önce çevreye verebileceğiniz zararları bir kez daha 
düşününüz. *
*Think of the environment once more before printing out this 
message.*
-- 
https://mail.python.org/mailman/listinfo/python-list

Short Survey About Requirements Engineering

[ETEM ÇETİN TOPTANİ]

Dear Sir or Madam,


We prepared a short survey to understand practitioners’ perspectives
towards the requirements engineering. Our survey basically aims to clarify
on many aspects of the requirements engineering applied in industry, including
(i) requirements gathering and specifications, (ii) requirements
modifications, (iii) requirements analysis, and (iv) requirements
transformation. The survey results will be submitted to a reputable journal
on software engineering.


The survey takes about 2-10 minutes to participate, we would be so grateful
if you could separate your time. Also, please circulate the e-mail to
anyone who may be interested in.


The survey link: https://forms.gle/DhLqr15GXVhJhzzy6


All the best,

 Etem Çetin Toptani

-- 
*Bu mesajı yazdırmadan önce çevreye verebileceğiniz zararları bir kez daha 
düşününüz. *
*Think of the environment once more before printing out this 
message.*

-- 
*Bu mesajı yazdırmadan önce çevreye verebileceğiniz zararları bir kez daha 
düşününüz. *
*Think of the environment once more before printing out this 
message.*
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Stack Overflow Developer Survey

[omarabukhalifa]

On Sunday, 14 April 2019 08:40:54 UTC+2, Frank Millman  wrote:
> Hi all
> 
> Stack Overflow have just published the results of their 2019 Developer 
> Survey. Here is the link -
> 
> https://insights.stackoverflow.com/survey/2019?utm_source=Iterable&utm_medium=email&utm_campaign=dev-survey-2019
> 
> They summarise some of the top 'takeaways'. This is first on the list -
> 
> """
> Python, the fastest-growing major programming language, has risen in the 
> ranks of programming languages in our survey yet again, edging out Java 
> this year and standing as the second most loved language (behind Rust).
> """
> 
> I thought it was worth a mention.
> 
> Frank Millman

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Stack Overflow Developer Survey

[Shakti Kumar]

It is certainly worth the mention!
Kudos to all the core devs and the volunteers here for their
dedication making Python the Most Wanted and Second Most Loved
programming language this time !

Thanks,
Shakti


On Sun, 14 Apr 2019 at 12:14, Frank Millman  wrote:
>
> Hi all
>
> Stack Overflow have just published the results of their 2019 Developer
> Survey. Here is the link -
>
> https://insights.stackoverflow.com/survey/2019?utm_source=Iterable&utm_medium=email&utm_campaign=dev-survey-2019
>
> They summarise some of the top 'takeaways'. This is first on the list -
>
> """
> Python, the fastest-growing major programming language, has risen in the
> ranks of programming languages in our survey yet again, edging out Java
> this year and standing as the second most loved language (behind Rust).
> """
>
> I thought it was worth a mention.
>
> Frank Millman
>
> --
> https://mail.python.org/mailman/listinfo/python-list
-- 
https://mail.python.org/mailman/listinfo/python-list

Stack Overflow Developer Survey

[Frank Millman]

Hi all

Stack Overflow have just published the results of their 2019 Developer 
Survey. Here is the link -


https://insights.stackoverflow.com/survey/2019?utm_source=Iterable&utm_medium=email&utm_campaign=dev-survey-2019

They summarise some of the top 'takeaways'. This is first on the list -

"""
Python, the fastest-growing major programming language, has risen in the 
ranks of programming languages in our survey yet again, edging out Java 
this year and standing as the second most loved language (behind Rust).

"""

I thought it was worth a mention.

Frank Millman

--
https://mail.python.org/mailman/listinfo/python-list

Re: Python Packages Survey

[Jason Friedman]

On Fri, Jan 18, 2019 at 5:22 PM Cameron Davidson-Pilon <
cam.davidson.pi...@gmail.com> wrote:

> Hello! I invite you to participate in the Python Packages Survey - it takes
> less than a minute to complete, and will help open source developers
> understand their users' better. Thanks for participating!
>
> https://python-packages-survey.com/
>
> I took the plunge.  Other than smoke coming out of my computer everything
seems to be normal.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python Packages Survey

[Chris Warrick]

On Sat, 19 Jan 2019 at 01:22, Cameron Davidson-Pilon
 wrote:
>
> Hello! I invite you to participate in the Python Packages Survey - it takes
> less than a minute to complete, and will help open source developers
> understand their users' better. Thanks for participating!
>
> https://python-packages-survey.com/

The site says:

> Completing the survey is as easy as running a Python script

No, thanks. A better way to get meaningful results is to just create a
good old web form, where you can ask people more detailed questions
than just mining the installed package list. Also, even if you promise
to filter out private packages, they *do* reach your server, and many
people would prefer that didn’t happen.

-- 
Chris Warrick <https://chriswarrick.com/>
PGP: 5EAAEA16
-- 
https://mail.python.org/mailman/listinfo/python-list

Python Packages Survey

[Cameron Davidson-Pilon]

Hello! I invite you to participate in the Python Packages Survey - it takes
less than a minute to complete, and will help open source developers
understand their users' better. Thanks for participating!

https://python-packages-survey.com/

-- 

Cameron Davidson-Pilon
Data Origami <https://dataorigami.net>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Quick survey: locals in comprehensions (Python 3 only)

[Tim Chase]

From: Tim Chase 

On 2018-06-23 23:08, Jim Lee wrote:
>>> On 06/23/2018 10:03 PM, Steven D'Aprano wrote:
 def test():
   a = 1
   b = 2
   result = [value for key, value in locals().items()]
   return result

 what would you expect the result of calling test() to be?
>>>
>>> I would *expect* [1, 2, None], though I haven't actually tried
>>> running it.
>> Interesting. Where do you get the None from?
>
> There are three locals:Γ  a, b, and result.Γ

However at the time locals() is called/evaluated, "result" hasn't yet been
created/defined, so I wouldn't expect to see any representation of "result" in
the return value.  If it existed before the locals() call, I would expect to
see the value it had before the call:

  def test()
a = 1
b = 2
result = "Steven"
result = [value for key, value in locals().items()]
return result
  test() # return [1, 2, "Steven"]


-tkc

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Quick survey: locals in comprehensions (Python 3 only)

[Tim Chase]

From: Tim Chase 

On 2018-06-24 05:03, Steven D'Aprano wrote:
> I'd like to run a quick survey. There is no right or wrong answer,
> since this is about your EXPECTATIONS, not what Python actually
> does.
>
> Given this function:
>
> def test():
> a = 1
> b = 2
> result = [value for key, value in locals().items()]
> return result
>
> what would you expect the result of calling test() to be?

I'd expect either [1,2] or [2,1] depending on whether it's py2 (where dict
iteration order isn't guaranteed, so could be either) or py3 (where dict order
is more stable/guaranteed)

> Is that the result you think is most useful?

While I have difficulty imagining a case in which I'd find this useful, if I
were writing this code, it's the "useful" result I'd expect.

> In your opinion, is this a useful feature, a misfeature, a bug, or
> "whatever"?

I'd file it in the "whatever" category, possibly useful to someone other than
me.

-tkc

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Quick survey: locals in comprehensions (Python 3 only)

[Ben Finney]

From: Ben Finney 

Paul Moore  writes:

> On 24 June 2018 at 06:03, Steven D'Aprano
>  wrote:
> > Given this function:
> >
> > def test():
> > a = 1
> > b = 2
> > result = [value for key, value in locals().items()]
> > return result
> >
> > what would you expect the result of calling test() to be? [Γ |]

> I'm aware of the background for this question. Is there any equivalent
> question that doesn't use locals()? The reason I ask is that I see
> locals() as "digging into implementation stuff" and sort of expect it
> to act oddly in situations like this...

My understanding of Steven's question is to give an unambiguous way to:

* Express the question Γ úwhich name bindings do you expect to exist in
  this local function scope, by the time of the Γ  returnΓ ╓ statement?Γ ╪.

* Avoid prejudicing the reader to expect any particular binding to be
  active.

One way to do the first, at the cost of losing the second, might be this::

def test():
a = 1
b = 2
[value for key, value in dict().items()]
print(a)
print(b)
print(key)
print(value)

and then ask Γ úWhich of those statements do you expect to fail with
NameError?Γ ╪.

But I may have misunderstood some nuance of what is being asked, which is to be
 expected because Steven was deliberately trying to avoid having the reader
second-guess what the purpose of the code is.

--
 \ Γ úI wish there was a knob on the TV to turn up the intelligence. |
  `\  There's a knob called Γ  brightnessΓ ╓ but it doesn't work.Γ ╪ |
_o__) Γ ÷Eugene P. Gallagher |
Ben Finney

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Quick survey: locals in comprehensions (Python 3 only)

[Paul Moore]

From: Paul Moore 

On 24 June 2018 at 06:03, Steven D'Aprano
 wrote:
> I'd like to run a quick survey. There is no right or wrong answer, since
> this is about your EXPECTATIONS, not what Python actually does.
>
> Given this function:
>
>
> def test():
> a = 1
> b = 2
> result = [value for key, value in locals().items()]
> return result
>
> what would you expect the result of calling test() to be? Is that the
> result you think is most useful? In your opinion, is this a useful
> feature, a misfeature, a bug, or "whatever"?
>
> I'm only looking for answers for Python 3. (The results in Python 2 are
> genuinely weird :-)

My immediate reaction was "that's not something I'd want to do, so I don't care
 (but I've a feeling it would be weird). On thinking some more, I decided that
[1, 2] made sense (but I still didn't actually care). After reading Chris
Angelico's analysis, I went back to my first opinion (that I don't care, but I
suspect it might be weird).

I'm aware of the background for this question. Is there any equivalent question
 that doesn't use locals()? The reason I ask is that I see locals() as "digging
 into implementation stuff" and sort of expect it to act oddly in situations
like this...

Paul

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Quick survey: locals in comprehensions (Python 3 only)

[Antoon Pardon]

On 26-06-18 12:39, Steven D'Aprano wrote:
> On Tue, 26 Jun 2018 12:04:16 +0200, Antoon Pardon wrote:
>
>> On 26-06-18 11:22, Steven D'Aprano wrote:
>>> On Tue, 26 Jun 2018 10:20:38 +0200, Antoon Pardon wrote:
>>>
> def test():
> a = 1
> b = 2
> result = [value for key, value in locals().items()] return result
>>> [...]
>>>
 I would expect an UnboundLocalError: local variable 'result'
 referenced before assignment.
>>> Well, I did say that there's no right or wrong answers, but that
>>> surprises me. Which line do you expect to fail, and why do you think
>>> "result" is unbound?
>> I would expect the third statement to fail because IMO we call the
>> locals function before result is bound. But result is a local variable
>> so the locals function will try to reference it, hence the
>> UnboundLocalError.
> Ah, I see. Thanks for the explanation.
>
> Given that locals() is capable of dealing with uninitialised local 
> variables without raising, would you like to revise your expectation?


Sure, I would now expect any |permutation of either a) [1, 2] or b) [1, 2, 
||UnboundLocalError|]

-- 
Antoon Pardon.


-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Quick survey: locals in comprehensions (Python 3 only)

[Steven D'Aprano]

On Tue, 26 Jun 2018 12:04:16 +0200, Antoon Pardon wrote:

> On 26-06-18 11:22, Steven D'Aprano wrote:
>> On Tue, 26 Jun 2018 10:20:38 +0200, Antoon Pardon wrote:
>>
 def test():
 a = 1
 b = 2
 result = [value for key, value in locals().items()] return result
>> [...]
>>
>>> I would expect an UnboundLocalError: local variable 'result'
>>> referenced before assignment.
>> Well, I did say that there's no right or wrong answers, but that
>> surprises me. Which line do you expect to fail, and why do you think
>> "result" is unbound?
> 
> I would expect the third statement to fail because IMO we call the
> locals function before result is bound. But result is a local variable
> so the locals function will try to reference it, hence the
> UnboundLocalError.

Ah, I see. Thanks for the explanation.

Given that locals() is capable of dealing with uninitialised local 
variables without raising, would you like to revise your expectation?



-- 
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Quick survey: locals in comprehensions (Python 3 only)

[Paul Moore]

On 26 June 2018 at 11:09, Chris Angelico  wrote:
> On Tue, Jun 26, 2018 at 8:04 PM, Antoon Pardon  wrote:
>> On 26-06-18 11:22, Steven D'Aprano wrote:
>>> On Tue, 26 Jun 2018 10:20:38 +0200, Antoon Pardon wrote:
>>>
> def test():
> a = 1
> b = 2
> result = [value for key, value in locals().items()]
> return result
>>> [...]
>>>
 I would expect an UnboundLocalError: local variable 'result' referenced
 before assignment.
>>> Well, I did say that there's no right or wrong answers, but that
>>> surprises me. Which line do you expect to fail, and why do you think
>>> "result" is unbound?
>>
>> I would expect the third statement to fail because IMO we call the locals
>> function before result is bound. But result is a local variable so the
>> locals function will try to reference it, hence the UnboundLocalError.
>
> Would you expect the same behaviour from this function?
>
> def test():
> a = 1
> b = 2
> result = locals()
> return result

Regardless of the answer to that question, the message here is
basically "people don't have good intuition of how locals() works". Or
to put it another way, "code that uses locals() is already something
you should probably be checking the docs for if you care about the
details of what it does". Which agrees with my immediate reaction when
I saw the original question :-)

Paul
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Quick survey: locals in comprehensions (Python 3 only)

[Antoon Pardon]

On 26-06-18 12:09, Chris Angelico wrote:
> On Tue, Jun 26, 2018 at 8:04 PM, Antoon Pardon  wrote:
>> On 26-06-18 11:22, Steven D'Aprano wrote:
>>> On Tue, 26 Jun 2018 10:20:38 +0200, Antoon Pardon wrote:
>>>
> def test():
> a = 1
> b = 2
> result = [value for key, value in locals().items()]
> return result
>>> [...]
>>>
 I would expect an UnboundLocalError: local variable 'result' referenced
 before assignment.
>>> Well, I did say that there's no right or wrong answers, but that
>>> surprises me. Which line do you expect to fail, and why do you think
>>> "result" is unbound?
>> I would expect the third statement to fail because IMO we call the locals
>> function before result is bound. But result is a local variable so the
>> locals function will try to reference it, hence the UnboundLocalError.
> Would you expect the same behaviour from this function?
>
> def test():
> a = 1
> b = 2
> result = locals()
> return result
>
> ChrisA

Yes, but not to the same degree. Somehow I expect this function to produce a
dictionary that has "result" as key, yet will raise an error when you try
to access the value associated with that key.

But in the original "items" is called, so that tries to reference the value
immediatly and so I expect an error immediatly.

-- 
Antoon Pardon. 

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Quick survey: locals in comprehensions (Python 3 only)

[Chris Angelico]

On Tue, Jun 26, 2018 at 8:04 PM, Antoon Pardon  wrote:
> On 26-06-18 11:22, Steven D'Aprano wrote:
>> On Tue, 26 Jun 2018 10:20:38 +0200, Antoon Pardon wrote:
>>
 def test():
 a = 1
 b = 2
 result = [value for key, value in locals().items()]
 return result
>> [...]
>>
>>> I would expect an UnboundLocalError: local variable 'result' referenced
>>> before assignment.
>> Well, I did say that there's no right or wrong answers, but that
>> surprises me. Which line do you expect to fail, and why do you think
>> "result" is unbound?
>
> I would expect the third statement to fail because IMO we call the locals
> function before result is bound. But result is a local variable so the
> locals function will try to reference it, hence the UnboundLocalError.

Would you expect the same behaviour from this function?

def test():
a = 1
b = 2
result = locals()
return result

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Quick survey: locals in comprehensions (Python 3 only)

[Antoon Pardon]

On 26-06-18 11:22, Steven D'Aprano wrote:
> On Tue, 26 Jun 2018 10:20:38 +0200, Antoon Pardon wrote:
>
>>> def test():
>>> a = 1
>>> b = 2
>>> result = [value for key, value in locals().items()]
>>> return result
> [...]
>
>> I would expect an UnboundLocalError: local variable 'result' referenced
>> before assignment.
> Well, I did say that there's no right or wrong answers, but that 
> surprises me. Which line do you expect to fail, and why do you think 
> "result" is unbound?

I would expect the third statement to fail because IMO we call the locals
function before result is bound. But result is a local variable so the
locals function will try to reference it, hence the UnboundLocalError.

-- 
Antoon Pardon.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Quick survey: locals in comprehensions (Python 3 only)

[Steven D'Aprano]

On Tue, 26 Jun 2018 10:20:38 +0200, Antoon Pardon wrote:

>> def test():
>> a = 1
>> b = 2
>> result = [value for key, value in locals().items()]
>> return result
[...]

> I would expect an UnboundLocalError: local variable 'result' referenced
> before assignment.

Well, I did say that there's no right or wrong answers, but that 
surprises me. Which line do you expect to fail, and why do you think 
"result" is unbound?



-- 
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Quick survey: locals in comprehensions (Python 3 only)

[Antoon Pardon]

On 24-06-18 07:03, Steven D'Aprano wrote:
> I'd like to run a quick survey. There is no right or wrong answer, since 
> this is about your EXPECTATIONS, not what Python actually does.
>
> Given this function:
>
>
> def test():
> a = 1
> b = 2
> result = [value for key, value in locals().items()]
> return result
>
>
>
>
> what would you expect the result of calling test() to be? Is that the 
> result you think is most useful? In your opinion, is this a useful 
> feature, a misfeature, a bug, or "whatever"?
>
> I'm only looking for answers for Python 3. (The results in Python 2 are 
> genuinely weird :-)

I would expect an UnboundLocalError: local variable 'result' referenced before 
assignment.

-- 
Antoon Pardon.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Quick survey: locals in comprehensions (Python 3 only)

[Jim Lee]

From: Jim Lee 



On 06/23/2018 11:02 PM, Chris Angelico wrote:
> On Sun, Jun 24, 2018 at 3:44 PM, Jim Lee  wrote:
>>
>> On 06/23/2018 10:03 PM, Steven D'Aprano wrote:
>>> I'd like to run a quick survey. There is no right or wrong answer, since
>>> this is about your EXPECTATIONS, not what Python actually does.
>>>
>>> Given this function:
>>>
>>>
>>> def test():
>>>   a = 1
>>>   b = 2
>>>   result = [value for key, value in locals().items()]
>>>   return result
>>>
>>>
>>>
>>>
>>> what would you expect the result of calling test() to be? Is that the
>>> result you think is most useful? In your opinion, is this a useful
>>> feature, a misfeature, a bug, or "whatever"?
>>>
>>> I'm only looking for answers for Python 3. (The results in Python 2 are
>>> genuinely weird :-)
>>>
>>>
>> I would *expect* [1, 2, None], though I haven't actually tried running it.
>>
> Interesting. Where do you get the None from? Suppose it had been "key
> for..." instead of "value", what would the third key have been? ["a",
> "b", ...]
>
> ChrisA
There are three locals:Γ  a, b, and result.Γ  Since result cannot be assigned a
 value until the list comp has been evaluated, I would expect the comp to
return a value of "None" for result.Γ  An argument could also be made for [1,
2, []], but one thing I would *not* expect is [1, 2] or [2, 1]...

-Jim

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Quick survey: locals in comprehensions (Python 3 only)

[Jim Lee]

From: Jim Lee 



On 06/23/2018 10:03 PM, Steven D'Aprano wrote:
> I'd like to run a quick survey. There is no right or wrong answer, since
> this is about your EXPECTATIONS, not what Python actually does.
>
> Given this function:
>
>
> def test():
>  a = 1
>  b = 2
>  result = [value for key, value in locals().items()]
>  return result
>
>
>
>
> what would you expect the result of calling test() to be? Is that the
> result you think is most useful? In your opinion, is this a useful
> feature, a misfeature, a bug, or "whatever"?
>
> I'm only looking for answers for Python 3. (The results in Python 2 are
> genuinely weird :-)
>
>
I would *expect* [1, 2, None], though I haven't actually tried running it.

-Jim

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Quick survey: locals in comprehensions (Python 3 only)

[Steven D'Aprano]

From: Steven D'Aprano 

On Sun, 24 Jun 2018 15:18:49 +1000, Chris Angelico wrote:

> Personally, I think it should give you [1, 2], the two values from the
> function's locals.

Thank you, that's the sort of answer I'm looking for.

(I'm not saying I didn't read your long and involved analysis, only that I'm
not looking for long involved analyses at the moment :-)


--
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing it everywhere."
 -- Jon Ronson

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Quick survey: locals in comprehensions (Python 3 only)

[Chris Angelico]

From: Chris Angelico 

On Sun, Jun 24, 2018 at 3:03 PM, Steven D'Aprano
 wrote:
> I'd like to run a quick survey. There is no right or wrong answer, since
> this is about your EXPECTATIONS, not what Python actually does.
>
> Given this function:
>
>
> def test():
> a = 1
> b = 2
> result = [value for key, value in locals().items()]
> return result
>
>
>
>
> what would you expect the result of calling test() to be? Is that the
> result you think is most useful? In your opinion, is this a useful
> feature, a misfeature, a bug, or "whatever"?
>
> I'm only looking for answers for Python 3. (The results in Python 2 are
> genuinely weird :-)

Personally, I think it should give you [1, 2], the two values from the
function's locals. But genexps introduce some problems. Compare:

def test():
a = 1
b = 2
result = list(value for key, value in locals().items())
return result

def test_helper():
a = 1
b = 2
gen = (value for key, value in locals().items())
return gen
def test():
return list(test_helper())

Guido has stated that he wants the list comp to be equivalent to calling list()
 immediately on the genexp. And since a genexp has to be the same thing whether
 you call list() on it straight away or not, that means that all these need to
behave the same way. Which, in turn, means that the genexp needs some form of
closure semantics. Thus it is executed in an implicit nested function, and thus
 the list comp also needs to be, for consistency.

So! With that in mind, I would consider bizarre behaviour of locals() inside
comprehensions to be a wart. It's not a normal thing to do, and if it behaves
weirdly, so be it. There are other things that I would prefer to see tidied up
before that.

ChrisA

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Quick survey: locals in comprehensions (Python 3 only)

[Jim Lee]

From: Jim Lee 



On 06/23/2018 11:16 PM, Chris Angelico wrote:
> On Sun, Jun 24, 2018 at 4:08 PM, Jim Lee  wrote:
>> There are three locals:  a, b, and result.  Since result cannot be assigned
>> a value until the list comp has been evaluated, I would expect the comp to
>> return a value of "None" for result.  An argument could also be made for [1,
>> 2, []], but one thing I would *not* expect is [1, 2] or [2, 1]...
> Ahh, I see what you mean. Thing is, there's a definite difference
> between "this is None" and "this doesn't have a value". The latter
> situation is indicated by simply not having the local.
>
> def f():
>  print("; ".join("%s=%r" % x for x in locals().items()))
>  a = 1
>  print("; ".join("%s=%r" % x for x in locals().items()))
>  b = 2
>  print("; ".join("%s=%r" % x for x in locals().items()))
>
> The results may surprise you, or may not.
>
> This part has nothing to do with the behaviour of locals inside a
> comprehension, though. The important part is that, like me, you would
> like comprehensions to represent a block of code inside the current
> function, not an implicit nested function.
>
> ChrisA
That's why I said an argument could be made for [1, 2, []].Γ  I realize that
NoneType is not the same as no type, but, having not studied the internals of
any particular Python implementation,Γ  I don't know how it builds or
initializes its local symbol table. But, I expected "result" to exist before
the list comprehension was evaluated simply due to left->right parsing.

-Jim

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Quick survey: locals in comprehensions (Python 3 only)

[Chris Angelico]

From: Chris Angelico 

On Sun, Jun 24, 2018 at 4:08 PM, Jim Lee  wrote:
> There are three locals:  a, b, and result.  Since result cannot be assigned
> a value until the list comp has been evaluated, I would expect the comp to
> return a value of "None" for result.  An argument could also be made for [1,
> 2, []], but one thing I would *not* expect is [1, 2] or [2, 1]...

Ahh, I see what you mean. Thing is, there's a definite difference between "this
 is None" and "this doesn't have a value". The latter situation is indicated by
 simply not having the local.

def f():
print("; ".join("%s=%r" % x for x in locals().items()))
a = 1
print("; ".join("%s=%r" % x for x in locals().items()))
b = 2
print("; ".join("%s=%r" % x for x in locals().items()))

The results may surprise you, or may not.

This part has nothing to do with the behaviour of locals inside a
comprehension, though. The important part is that, like me, you would like
comprehensions to represent a block of code inside the current function, not an
 implicit nested function.

ChrisA

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Quick survey: locals in comprehensions (Python 3 only)

[Chris Angelico]

From: Chris Angelico 

On Sun, Jun 24, 2018 at 3:44 PM, Jim Lee  wrote:
>
>
> On 06/23/2018 10:03 PM, Steven D'Aprano wrote:
>>
>> I'd like to run a quick survey. There is no right or wrong answer, since
>> this is about your EXPECTATIONS, not what Python actually does.
>>
>> Given this function:
>>
>>
>> def test():
>>  a = 1
>>  b = 2
>>  result = [value for key, value in locals().items()]
>>  return result
>>
>>
>>
>>
>> what would you expect the result of calling test() to be? Is that the
>> result you think is most useful? In your opinion, is this a useful
>> feature, a misfeature, a bug, or "whatever"?
>>
>> I'm only looking for answers for Python 3. (The results in Python 2 are
>> genuinely weird :-)
>>
>>
> I would *expect* [1, 2, None], though I haven't actually tried running it.
>

Interesting. Where do you get the None from? Suppose it had been "key for..."
instead of "value", what would the third key have been? ["a", "b", ...]

ChrisA

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Quick survey: locals in comprehensions (Python 3 only)

[Steven D'Aprano]

From: Steven D'Aprano 

I'd like to run a quick survey. There is no right or wrong answer, since this
is about your EXPECTATIONS, not what Python actually does.

Given this function:


def test():
a = 1
b = 2
result = [value for key, value in locals().items()]
return result




what would you expect the result of calling test() to be? Is that the result
you think is most useful? In your opinion, is this a useful feature, a
misfeature, a bug, or "whatever"?

I'm only looking for answers for Python 3. (The results in Python 2 are
genuinely weird :-)


--
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing it everywhere."
 -- Jon Ronson

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Quick survey: locals in comprehensions (Python 3 only)

[Tim Chase]

On 2018-06-23 23:08, Jim Lee wrote:
>>> On 06/23/2018 10:03 PM, Steven D'Aprano wrote:  
 def test():
   a = 1
   b = 2
   result = [value for key, value in locals().items()]
   return result

 what would you expect the result of calling test() to be?
>>>  
>>> I would *expect* [1, 2, None], though I haven't actually tried
>>> running it. 
>> Interesting. Where do you get the None from?
>
> There are three locals:  a, b, and result. 

However at the time locals() is called/evaluated, "result" hasn't yet
been created/defined, so I wouldn't expect to see any representation
of "result" in the return value.  If it existed before the locals()
call, I would expect to see the value it had before the call:

  def test()
a = 1
b = 2
result = "Steven"
result = [value for key, value in locals().items()]
return result
  test() # return [1, 2, "Steven"]


-tkc




-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Quick survey: locals in comprehensions (Python 3 only)

[Tim Chase]

On 2018-06-24 05:03, Steven D'Aprano wrote:
> I'd like to run a quick survey. There is no right or wrong answer,
> since this is about your EXPECTATIONS, not what Python actually
> does.
> 
> Given this function:
> 
> def test():
> a = 1
> b = 2
> result = [value for key, value in locals().items()]
> return result
> 
> what would you expect the result of calling test() to be?

I'd expect either [1,2] or [2,1] depending on whether it's py2 (where
dict iteration order isn't guaranteed, so could be either) or py3
(where dict order is more stable/guaranteed)

> Is that the result you think is most useful?

While I have difficulty imagining a case in which I'd find this
useful, if I were writing this code, it's the "useful" result I'd
expect.

> In your opinion, is this a useful feature, a misfeature, a bug, or
> "whatever"?

I'd file it in the "whatever" category, possibly useful to someone
other than me.

-tkc


-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Quick survey: locals in comprehensions (Python 3 only)

[Ben Finney]

Paul Moore  writes:

> On 24 June 2018 at 06:03, Steven D'Aprano
>  wrote:
> > Given this function:
> >
> > def test():
> > a = 1
> > b = 2
> > result = [value for key, value in locals().items()]
> > return result
> >
> > what would you expect the result of calling test() to be? […]

> I'm aware of the background for this question. Is there any equivalent
> question that doesn't use locals()? The reason I ask is that I see
> locals() as "digging into implementation stuff" and sort of expect it
> to act oddly in situations like this...

My understanding of Steven's question is to give an unambiguous way to:

* Express the question “which name bindings do you expect to exist in
  this local function scope, by the time of the ‘return’ statement?”.

* Avoid prejudicing the reader to expect any particular binding to be
  active.

One way to do the first, at the cost of losing the second, might be
this::

def test():
a = 1
b = 2
[value for key, value in dict().items()]
print(a)
print(b)
print(key)
print(value)

and then ask “Which of those statements do you expect to fail with
NameError?”.

But I may have misunderstood some nuance of what is being asked, which
is to be expected because Steven was deliberately trying to avoid having
the reader second-guess what the purpose of the code is.

-- 
 \ “I wish there was a knob on the TV to turn up the intelligence. |
  `\  There's a knob called ‘brightness’ but it doesn't work.” |
_o__) —Eugene P. Gallagher |
Ben Finney

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Quick survey: locals in comprehensions (Python 3 only)

[Paul Moore]

On 24 June 2018 at 06:03, Steven D'Aprano
 wrote:
> I'd like to run a quick survey. There is no right or wrong answer, since
> this is about your EXPECTATIONS, not what Python actually does.
>
> Given this function:
>
>
> def test():
> a = 1
> b = 2
> result = [value for key, value in locals().items()]
> return result
>
> what would you expect the result of calling test() to be? Is that the
> result you think is most useful? In your opinion, is this a useful
> feature, a misfeature, a bug, or "whatever"?
>
> I'm only looking for answers for Python 3. (The results in Python 2 are
> genuinely weird :-)

My immediate reaction was "that's not something I'd want to do, so I
don't care (but I've a feeling it would be weird). On thinking some
more, I decided that [1, 2] made sense (but I still didn't actually
care). After reading Chris Angelico's analysis, I went back to my
first opinion (that I don't care, but I suspect it might be weird).

I'm aware of the background for this question. Is there any equivalent
question that doesn't use locals()? The reason I ask is that I see
locals() as "digging into implementation stuff" and sort of expect it
to act oddly in situations like this...

Paul
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Quick survey: locals in comprehensions (Python 3 only)

[Jim Lee]

On 06/23/2018 11:16 PM, Chris Angelico wrote:

On Sun, Jun 24, 2018 at 4:08 PM, Jim Lee  wrote:

There are three locals:  a, b, and result.  Since result cannot be assigned
a value until the list comp has been evaluated, I would expect the comp to
return a value of "None" for result.  An argument could also be made for [1,
2, []], but one thing I would *not* expect is [1, 2] or [2, 1]...

Ahh, I see what you mean. Thing is, there's a definite difference
between "this is None" and "this doesn't have a value". The latter
situation is indicated by simply not having the local.

def f():
 print("; ".join("%s=%r" % x for x in locals().items()))
 a = 1
 print("; ".join("%s=%r" % x for x in locals().items()))
 b = 2
 print("; ".join("%s=%r" % x for x in locals().items()))

The results may surprise you, or may not.

This part has nothing to do with the behaviour of locals inside a
comprehension, though. The important part is that, like me, you would
like comprehensions to represent a block of code inside the current
function, not an implicit nested function.

ChrisA
That's why I said an argument could be made for [1, 2, []].  I realize 
that NoneType is not the same as no type, but, having not studied the 
internals of any particular Python implementation,  I don't know how it 
builds or initializes its local symbol table. But, I expected "result" 
to exist before the list comprehension was evaluated simply due to 
left->right parsing.


-Jim

--
https://mail.python.org/mailman/listinfo/python-list

Re: Quick survey: locals in comprehensions (Python 3 only)

[Chris Angelico]

On Sun, Jun 24, 2018 at 4:08 PM, Jim Lee  wrote:
> There are three locals:  a, b, and result.  Since result cannot be assigned
> a value until the list comp has been evaluated, I would expect the comp to
> return a value of "None" for result.  An argument could also be made for [1,
> 2, []], but one thing I would *not* expect is [1, 2] or [2, 1]...

Ahh, I see what you mean. Thing is, there's a definite difference
between "this is None" and "this doesn't have a value". The latter
situation is indicated by simply not having the local.

def f():
print("; ".join("%s=%r" % x for x in locals().items()))
a = 1
print("; ".join("%s=%r" % x for x in locals().items()))
b = 2
print("; ".join("%s=%r" % x for x in locals().items()))

The results may surprise you, or may not.

This part has nothing to do with the behaviour of locals inside a
comprehension, though. The important part is that, like me, you would
like comprehensions to represent a block of code inside the current
function, not an implicit nested function.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Quick survey: locals in comprehensions (Python 3 only)

[Jim Lee]

On 06/23/2018 11:02 PM, Chris Angelico wrote:

On Sun, Jun 24, 2018 at 3:44 PM, Jim Lee  wrote:


On 06/23/2018 10:03 PM, Steven D'Aprano wrote:

I'd like to run a quick survey. There is no right or wrong answer, since
this is about your EXPECTATIONS, not what Python actually does.

Given this function:


def test():
  a = 1
  b = 2
  result = [value for key, value in locals().items()]
  return result




what would you expect the result of calling test() to be? Is that the
result you think is most useful? In your opinion, is this a useful
feature, a misfeature, a bug, or "whatever"?

I'm only looking for answers for Python 3. (The results in Python 2 are
genuinely weird :-)



I would *expect* [1, 2, None], though I haven't actually tried running it.


Interesting. Where do you get the None from? Suppose it had been "key
for..." instead of "value", what would the third key have been? ["a",
"b", ...]

ChrisA
There are three locals:  a, b, and result.  Since result cannot be 
assigned a value until the list comp has been evaluated, I would expect 
the comp to return a value of "None" for result.  An argument could also 
be made for [1, 2, []], but one thing I would *not* expect is [1, 2] or 
[2, 1]...


-Jim


--
https://mail.python.org/mailman/listinfo/python-list

Re: Quick survey: locals in comprehensions (Python 3 only)

[Chris Angelico]

On Sun, Jun 24, 2018 at 3:44 PM, Jim Lee  wrote:
>
>
> On 06/23/2018 10:03 PM, Steven D'Aprano wrote:
>>
>> I'd like to run a quick survey. There is no right or wrong answer, since
>> this is about your EXPECTATIONS, not what Python actually does.
>>
>> Given this function:
>>
>>
>> def test():
>>  a = 1
>>  b = 2
>>  result = [value for key, value in locals().items()]
>>  return result
>>
>>
>>
>>
>> what would you expect the result of calling test() to be? Is that the
>> result you think is most useful? In your opinion, is this a useful
>> feature, a misfeature, a bug, or "whatever"?
>>
>> I'm only looking for answers for Python 3. (The results in Python 2 are
>> genuinely weird :-)
>>
>>
> I would *expect* [1, 2, None], though I haven't actually tried running it.
>

Interesting. Where do you get the None from? Suppose it had been "key
for..." instead of "value", what would the third key have been? ["a",
"b", ...]

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Quick survey: locals in comprehensions (Python 3 only)

[Jim Lee]

On 06/23/2018 10:03 PM, Steven D'Aprano wrote:

I'd like to run a quick survey. There is no right or wrong answer, since
this is about your EXPECTATIONS, not what Python actually does.

Given this function:


def test():
 a = 1
 b = 2
 result = [value for key, value in locals().items()]
 return result




what would you expect the result of calling test() to be? Is that the
result you think is most useful? In your opinion, is this a useful
feature, a misfeature, a bug, or "whatever"?

I'm only looking for answers for Python 3. (The results in Python 2 are
genuinely weird :-)



I would *expect* [1, 2, None], though I haven't actually tried running it.

-Jim


--
https://mail.python.org/mailman/listinfo/python-list

Re: Quick survey: locals in comprehensions (Python 3 only)

[Steven D'Aprano]

On Sun, 24 Jun 2018 15:18:49 +1000, Chris Angelico wrote:

> Personally, I think it should give you [1, 2], the two values from the
> function's locals.

Thank you, that's the sort of answer I'm looking for.

(I'm not saying I didn't read your long and involved analysis, only that 
I'm not looking for long involved analyses at the moment :-)


-- 
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Quick survey: locals in comprehensions (Python 3 only)

[Chris Angelico]

On Sun, Jun 24, 2018 at 3:03 PM, Steven D'Aprano
 wrote:
> I'd like to run a quick survey. There is no right or wrong answer, since
> this is about your EXPECTATIONS, not what Python actually does.
>
> Given this function:
>
>
> def test():
> a = 1
> b = 2
> result = [value for key, value in locals().items()]
> return result
>
>
>
>
> what would you expect the result of calling test() to be? Is that the
> result you think is most useful? In your opinion, is this a useful
> feature, a misfeature, a bug, or "whatever"?
>
> I'm only looking for answers for Python 3. (The results in Python 2 are
> genuinely weird :-)

Personally, I think it should give you [1, 2], the two values from the
function's locals. But genexps introduce some problems. Compare:

def test():
a = 1
b = 2
result = list(value for key, value in locals().items())
return result

def test_helper():
a = 1
b = 2
gen = (value for key, value in locals().items())
return gen
def test():
return list(test_helper())

Guido has stated that he wants the list comp to be equivalent to
calling list() immediately on the genexp. And since a genexp has to be
the same thing whether you call list() on it straight away or not,
that means that all these need to behave the same way. Which, in turn,
means that the genexp needs some form of closure semantics. Thus it is
executed in an implicit nested function, and thus the list comp also
needs to be, for consistency.

So! With that in mind, I would consider bizarre behaviour of locals()
inside comprehensions to be a wart. It's not a normal thing to do, and
if it behaves weirdly, so be it. There are other things that I would
prefer to see tidied up before that.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Quick survey: locals in comprehensions (Python 3 only)

[Steven D'Aprano]

I'd like to run a quick survey. There is no right or wrong answer, since 
this is about your EXPECTATIONS, not what Python actually does.

Given this function:


def test():
a = 1
b = 2
result = [value for key, value in locals().items()]
return result




what would you expect the result of calling test() to be? Is that the 
result you think is most useful? In your opinion, is this a useful 
feature, a misfeature, a bug, or "whatever"?

I'm only looking for answers for Python 3. (The results in Python 2 are 
genuinely weird :-)


-- 
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python Developer Survey: Python 3 usage overtakes Python 2 usage

[Steven D'Aprano]

On Sat, 31 Mar 2018 14:07:37 -0400, Terry Reedy wrote:

> On 3/31/2018 11:58 AM, Etienne Robillard wrote:
> 
>> Do you really think people in Somalia can afford theses things like in
>> the US?
> 
> No, many cannot afford $600 Caddilac-style phones to take 10 megapixel
> pictures and watch UTube videos.  Instead they buy $100 VWBug-style
> phones that let them get competitive prices for their crops and other
> goods instead of accepting low-ball bids from whoever wanders by their
> village.
> 
> Africans are ahead of at least the US in using phone minutes as a benign
> practical digital currency.  This, not destructive and useless bitcoins,
> are the real revolution.

What Terry said.

Personally, I dislike smartphones, but I have to say that they way they 
are used in villages across India, Africa and other developing places has 
been far more of a benign revolution than what smartphones are doing to 
the West.


None of this has anything to do with Python though. Python is not 
primarily a device for development on mobile devices, it is not dropping 
support for laptops, desktops and servers, and Etienne's questions are 
based on utterly false premises.


-- 
Steve

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python Developer Survey: Python 3 usage overtakes Python 2 usage

[Steven D'Aprano]

On Sat, 31 Mar 2018 10:58:51 -0400, Etienne Robillard wrote:

> Hi,
> 
> I was just wondering, could the fact that the Python community is
> willing to discontinue using and developing Python 2 softwares, does
> that mean we are stopping to support standard computers and laptops as
> well?

That seems to be a strange question to ask, when servers and desktops are 
the primary focus of Python 3.


> Furthermore, does it bother you to develop code primarly oriented
> towards mobile devices in Python 3 while most of the world still cannot
> afford theses expensive products?

It doesn't bother me one bit, because I don't do it. Nor is Python mainly 
oriented towards mobile devices. In fact, getting Python working on 
mobile devices is still a bit of a challenge.



-- 
Steve

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python Developer Survey: Python 3 usage overtakes Python 2 usage

[Rick Johnson]

Grant Edwards wrote:
> Etienne Robillard wrote:
> 
> > Do you understand that a modern mobile device typically
> > require a Internet subscription and an additional
> > subscription for the smart phone?
> 
> Huh?  What is "an internet subscription"?  Why would you
> need two of them if all you have is a smartphone?

Most american cell providers these days offer an unlimited
"0talk and text" plan and then add an additional fee for smart
phones (aka: "Data Plan").
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python Developer Survey: Python 3 usage overtakes Python 2 usage

[Terry Reedy]

On 3/31/2018 11:58 AM, Etienne Robillard wrote:

Do you really think people in Somalia can afford theses things like in 
the US?


No, many cannot afford $600 Caddilac-style phones to take 10 megapixel 
pictures and watch UTube videos.  Instead they buy $100 VWBug-style 
phones that let them get competitive prices for their crops and other 
goods instead of accepting low-ball bids from whoever wanders by their 
village.


Africans are ahead of at least the US in using phone minutes as a benign 
practical digital currency.  This, not destructive and useless bitcoins, 
are the real revolution.


--
Terry Jan Reedy

--
https://mail.python.org/mailman/listinfo/python-list

Re: Python Developer Survey: Python 3 usage overtakes Python 2 usage

[Grant Edwards]

On 2018-03-31, Etienne Robillard  wrote:

> Are you trolling? Do you understand that a modern mobile device 
> typically require a Internet subscription and an additional subscription 
> for the smart phone?

Huh?  What is "an internet subscription"?

Why would you need two of them if all you have is a smartphone?

> Do you really think people in Somalia can afford theses things like in 
> the US?

I think you'll find that smartphones are far more widespread in both
rich and poor countries than are traditional computers and laptops.

-- 
Grant




-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python Developer Survey: Python 3 usage overtakes Python 2 usage

[Michael Torrie]

On Mar 31, 2018 09:58, "Etienne Robillard"  wrote:



Le 2018-03-31 à 11:40, Michael Torrie a écrit :

> On 03/31/2018 08:58 AM, Etienne Robillard wrote:
>
>> I was just wondering, could the fact that the Python community is
>> willing to discontinue using and developing Python 2 softwares, does
>>   that mean we are stopping to support standard computers and laptops
>> as well?
>>
> I've tried several times but I can't make sense of that paragraph.
>
Please give me a break. That was just a simple question. Besides, I really
don't understand why the Python development community is dropping support
for Python 2 unless for stopping to support standard computers altogether...

Why would dropping support for python 2 indicate an abandonment of
conventional desktop computers and operating systems?  Python3 is not a
mobile language. Why do you think it is?



> Furthermore, does it bother you to develop code primarly oriented
>> towards mobile devices in Python 3 while most of the world still
>> cannot afford theses expensive products?
>>
> Or this one.  What are you talking about?
>

Are you trolling? Do you understand that a modern mobile device typically
require a Internet subscription and an additional subscription for the
smart phone?


I'm not trolling. I genuinely don't understand where you're coming from.
What does python3 have to do with mobile development? I know of very little
mobile development happening with any version of python.


Do you really think people in Somalia can afford theses things like in the
US?


I can assure you that smart phones have made waves even in Somalia. As far
as it goes, I'm quite sure a smart phone is way cheaper than a desktop or
laptop.

But again I don't understand why you're talking about mobile as if python
is somehow abandoning desktop. You're coming from a false premise with that
one.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python Developer Survey: Python 3 usage overtakes Python 2 usage

[Anders Wegge Keller]

På Sat, 31 Mar 2018 11:58:39 -0400
Etienne Robillard  skrev:

> Are you trolling? Do you understand that a modern mobile device 
> typically require a Internet subscription and an additional subscription 
> for the smart phone?

 I think the question is why you equate python3 with the need for internet
connected tablets. That's quite the non sequitur. 

Consider this my +1 the the request of you to clarify what you mean.

-- 
//Wegge
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python Developer Survey: Python 3 usage overtakes Python 2 usage

[bartc]

On 31/03/2018 16:58, Etienne Robillard wrote:



Le 2018-03-31 à 11:40, Michael Torrie a écrit :

On 03/31/2018 08:58 AM, Etienne Robillard wrote:

I was just wondering, could the fact that the Python community is
willing to discontinue using and developing Python 2 softwares, does
  that mean we are stopping to support standard computers and laptops
as well?

I've tried several times but I can't make sense of that paragraph.
Please give me a break. That was just a simple question. Besides, I 
really don't understand why the Python development community is dropping 
support for Python 2 unless for stopping to support standard computers 
altogether...



Furthermore, does it bother you to develop code primarly oriented
towards mobile devices in Python 3 while most of the world still
cannot afford theses expensive products?

Or this one.  What are you talking about?


Are you trolling? Do you understand that a modern mobile device 
typically require a Internet subscription and an additional subscription 
for the smart phone?


AIUI, a smartphone or tablet will still work as a small computer without 
an internet or phone connection (ie. without any of WiFi/GSM/3G/4G).


But a temporary WiFi link (eg. a free one at McDonald's) can be useful 
to download extra free apps then they can be used off-line.


Of source it might not be very popular without access to social media if 
that's the main purpose of the device.


--
bartc

--
https://mail.python.org/mailman/listinfo/python-list

Re: Python Developer Survey: Python 3 usage overtakes Python 2 usage

[Chris Angelico]

On Sun, Apr 1, 2018 at 2:58 AM, Etienne Robillard  wrote:
>
>
> Le 2018-03-31 à 11:40, Michael Torrie a écrit :
>>
>> On 03/31/2018 08:58 AM, Etienne Robillard wrote:
>>>
>>> I was just wondering, could the fact that the Python community is
>>> willing to discontinue using and developing Python 2 softwares, does
>>>   that mean we are stopping to support standard computers and laptops
>>> as well?
>>
>> I've tried several times but I can't make sense of that paragraph.
>
> Please give me a break. That was just a simple question. Besides, I really
> don't understand why the Python development community is dropping support
> for Python 2 unless for stopping to support standard computers altogether...

How are they related? What does the termination of support for a
ten-year-old version of Python have to do with forcing everyone to
mobile devices that they don't own?

You might as well ask if after 2020 there will be no further support
for OSX, or no further support for compilers other than gcc, or no
further support for 64-bit computers.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python Developer Survey: Python 3 usage overtakes Python 2 usage

[Etienne Robillard]

Le 2018-03-31 à 11:40, Michael Torrie a écrit :

On 03/31/2018 08:58 AM, Etienne Robillard wrote:

I was just wondering, could the fact that the Python community is
willing to discontinue using and developing Python 2 softwares, does
  that mean we are stopping to support standard computers and laptops
as well?

I've tried several times but I can't make sense of that paragraph.
Please give me a break. That was just a simple question. Besides, I 
really don't understand why the Python development community is dropping 
support for Python 2 unless for stopping to support standard computers 
altogether...



Furthermore, does it bother you to develop code primarly oriented
towards mobile devices in Python 3 while most of the world still
cannot afford theses expensive products?

Or this one.  What are you talking about?


Are you trolling? Do you understand that a modern mobile device 
typically require a Internet subscription and an additional subscription 
for the smart phone?


Do you really think people in Somalia can afford theses things like in 
the US?



Etienne

--
Etienne Robillard
tkad...@yandex.com
https://www.isotopesoftware.ca/

--
https://mail.python.org/mailman/listinfo/python-list

Re: Python Developer Survey: Python 3 usage overtakes Python 2 usage

[Michael Torrie]

On 03/31/2018 08:58 AM, Etienne Robillard wrote:
> I was just wondering, could the fact that the Python community is 
> willing to discontinue using and developing Python 2 softwares, does
>  that mean we are stopping to support standard computers and laptops
> as well?

I've tried several times but I can't make sense of that paragraph.

> Furthermore, does it bother you to develop code primarly oriented 
> towards mobile devices in Python 3 while most of the world still
> cannot afford theses expensive products?

Or this one.  What are you talking about?

Regarding mobile development, I'd love to write mobile apps with
Python3.  At present, though, that's not very practical.  Python isn't
geared at all towards mobile space, and Apple and Google don't have any
interest in supporting much besides Obj C/Swift or a Java-based language
as a first class development language.

Just as an aside, many more people in the world can afford a smart phone
now than a "standard computer" or laptop. Probably an order of
magnitude.  Just saying.  I've seen smart phones all over the developing
world.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python Developer Survey: Python 3 usage overtakes Python 2 usage

[Etienne Robillard]

Hi,

I was just wondering, could the fact that the Python community is 
willing to discontinue using and developing Python 2 softwares, does 
that mean we are stopping to support standard computers and laptops as well?


Furthermore, does it bother you to develop code primarly oriented 
towards mobile devices in Python 3 while most of the world still cannot 
afford theses expensive products?


Etienne

--
Etienne Robillard
tkad...@yandex.com
https://www.isotopesoftware.ca/

--
https://mail.python.org/mailman/listinfo/python-list

Re: Python Developer Survey: Python 3 usage overtakes Python 2 usage

[Gene Heskett]

On Saturday 31 March 2018 10:16:13 Ian Kelly wrote:

> On Sat, Mar 31, 2018 at 6:29 AM, Rick Johnson
>
>  wrote:
> > On Friday, March 30, 2018 at 8:59:16 PM UTC-5, Chris Angelico wrote:
> >> Wanna provide some competing information showing that other
> >> languages are more used?
> >
> > Chris, here is how debate works:
> >
> > PersonA asserts X.
> >
> > PersonB demands evidence for X.
> >
> > PersonA either provides evidence for X, or X is rejected as
> > hooey.
>
> PersonB provides evidence fox X.
>
> PersonA asserts that that evidence doesn't count because "it's
> nothin' but hype".
>
> PersonC provides a different source of numbers supporting X.
>
> PersonA asserts that those numbers don't count either because most
> of them are trolls or sock puppets.
>
> PersonD asks if PersonA has any of their own evidence to provide.
>
> PersonA snarkily responds that they don't need to provide evidence
> because they didn't make the assertion, apparently oblivious to the
> fact that they've actually made several assertions of their own over
> the course of this.
>
> Do I have this right? This is how I understand debate works from
> following this thread. I see the same pattern on the Flat-Earth
> threads, so I think I have it right.

Close enough for the girls I go with. 


-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python Developer Survey: Python 3 usage overtakes Python 2 usage

[Ian Kelly]

On Sat, Mar 31, 2018 at 6:29 AM, Rick Johnson
 wrote:
> On Friday, March 30, 2018 at 8:59:16 PM UTC-5, Chris Angelico wrote:
>> Wanna provide some competing information showing that other
>> languages are more used?
>
> Chris, here is how debate works:
>
> PersonA asserts X.
>
> PersonB demands evidence for X.
>
> PersonA either provides evidence for X, or X is rejected as
> hooey.

PersonB provides evidence fox X.

PersonA asserts that that evidence doesn't count because "it's
nothin' but hype".

PersonC provides a different source of numbers supporting X.

PersonA asserts that those numbers don't count either because most
of them are trolls or sock puppets.

PersonD asks if PersonA has any of their own evidence to provide.

PersonA snarkily responds that they don't need to provide evidence
because they didn't make the assertion, apparently oblivious to the
fact that they've actually made several assertions of their own over
the course of this.

Do I have this right? This is how I understand debate works from
following this thread. I see the same pattern on the Flat-Earth
threads, so I think I have it right.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python Developer Survey: Python 3 usage overtakes Python 2 usage

[Chris Angelico]

On Sat, Mar 31, 2018 at 11:29 PM, Rick Johnson
 wrote:
> Under no circumstance is PersonB required to prove PersonA'a
> assertions. The onerous is on PersonA.

Assertion: Rick doesn't know what "onerous" means.

Under no circumstance is Rick required to prove me right. But he
obliged anyway. Very kind of him.

This has nothing to do with any sort of debate; I just thought it interesting.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python Developer Survey: Python 3 usage overtakes Python 2 usage

[Rick Johnson]

On Friday, March 30, 2018 at 8:59:16 PM UTC-5, Chris Angelico wrote:
[...]
> You can pooh-pooh any statistic. 

Yeah, except the ones supported by actual _facts_.

> So far, though, you have provided NO statistics of your
> own, just your own gut feeling. 

Uh huh. And what do you call drawing naive conclusions from
statistical data? I'd call it confirmation bias!

> Wanna provide some competing information showing that other
> languages are more used?

Chris, here is how debate works:

PersonA asserts X.

PersonB demands evidence for X.

PersonA either provides evidence for X, or X is rejected as
hooey.

Under no circumstance is PersonB required to prove PersonA'a
assertions. The onerous is on PersonA.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python Developer Survey: Python 3 usage overtakes Python 2 usage

[Steven D'Aprano]

On Sat, 31 Mar 2018 12:39:48 +0300, Marko Rauhamaa wrote:

> Paul Rubin :
>> All the scripts that say #!/usr/bin/python at the top will still use
>> python2.
> 
> Which is how it should be till the end of times.

Don't be silly -- they should use Python 1, of course, as nature 
intended. In 20 years time, when we're using Python 5.2 and Python 3 is a 
distant memory, typing "python" at the command prompt should try to 
launch Python1.x.

If you think that's ludicrous, consider that replacing 1.x with 2.x 
doesn't make it any less ludicrous.


> Unfortunately, ArchLinux decided otherwise, which has caused quite a bit
> of grief in the office, where a coworker uses it.
> 
> We thought we could get around the problem by specifying
> 
>#!/usr/bin/env python2
> 
> in all of our scripts, but, regrettably,
> 
>(1) Not all of our python tools are written by us

Nevertheless, they're text files on your server which can easily have a 
tiny sed script run over them as part of the deployment process, or a 
thin wrapper in bash, or your tech staff could add an alias to their bash 
login script (or equivalent).

Or just get the Archlinux guy to add an alias to his logic script.



>(2) MacOS doesn't have a python2 alias for Python2

o_O

Um... is your tech team made up of actual techs or do you ask your 
grandma[1] to administrate your system? How hard is it to add a python2 
alias on MacOS?

That's a rhetorical question -- the answer is, "not hard at all".




[1] For all I know, Marko's grandma could have invented Unix. If that's 
the case, substitute my grandma, who certain did not.



-- 
Steve

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python Developer Survey: Python 3 usage overtakes Python 2 usage

[Steven D'Aprano]

On Sat, 31 Mar 2018 12:32:31 +0300, Marko Rauhamaa wrote:

> Paul Rubin :
> 
>> Marko Rauhamaa  writes:
>>> Yes, RHEL, CentOS and OracleLinux still only support Python2. It may
>>> be another year before Python3 becomes available on them.
>>
>> Debian's default Python is also Python2. I don't say it *only* supports
>> python2 since you can optionally install python3,
> 
> That option is not available for RHEL et al.

Python 3.3 was available for RHEL 6:

https://access.redhat.com/solutions/123273

I would be shocked if RedHat 7 didn't support 3.3, at the very least.



-- 
Steve

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python Developer Survey: Python 3 usage overtakes Python 2 usage

[Marko Rauhamaa]

Paul Rubin :
> All the scripts that say #!/usr/bin/python at the top will still use
> python2.

Which is how it should be till the end of times.

Unfortunately, ArchLinux decided otherwise, which has caused quite a bit
of grief in the office, where a coworker uses it.

We thought we could get around the problem by specifying

   #!/usr/bin/env python2

in all of our scripts, but, regrettably,

   (1) Not all of our python tools are written by us

   (2) MacOS doesn't have a python2 alias for Python2

> Typing "python" or "python xyz.py" at the shell will also use python2.
> Python3 will have really taken over when it's the other way around and
> python2 is the optional install.

I disagree. It is enough for the oldest supported Linux and MacOS distro
to support Python3 out of the box.


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python Developer Survey: Python 3 usage overtakes Python 2 usage

[Marko Rauhamaa]

Paul Rubin :

> Marko Rauhamaa  writes:
>> Yes, RHEL, CentOS and OracleLinux still only support Python2. It may
>> be another year before Python3 becomes available on them.
>
> Debian's default Python is also Python2. I don't say it *only*
> supports python2 since you can optionally install python3,

That option is not available for RHEL et al. It is expected that RHEL 8
will include Python3, but nobody knows when RHEL 8 will come out.


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python Developer Survey: Python 3 usage overtakes Python 2 usage

[Steven D'Aprano]

On Fri, 30 Mar 2018 20:51:22 -0600, Ian Kelly wrote:

> On Fri, Mar 30, 2018 at 8:43 PM, Ian Kelly 
> wrote:
>> You really think that 90% of the active users are trolls? And yet the
>> subreddit remains usable despite that allegedly terrible
>> signal-to-noise ratio.
> 
> I'm now laughing at the image of a large community of trolls sitting
> around trolling each other and not realizing that they're all being
> trolled.


/TheDonald ?



*ducks and hides*



-- 
Steve

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python Developer Survey: Python 3 usage overtakes Python 2 usage

[Chris Angelico]

On Sat, Mar 31, 2018 at 1:51 PM, Ian Kelly  wrote:
> On Fri, Mar 30, 2018 at 8:43 PM, Ian Kelly  wrote:
>> You really think that 90% of the active users are trolls? And yet the
>> subreddit remains usable despite that allegedly terrible
>> signal-to-noise ratio.
>
> I'm now laughing at the image of a large community of trolls sitting
> around trolling each other and not realizing that they're all being
> trolled.

Isn't that the definition of "social media"?

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python Developer Survey: Python 3 usage overtakes Python 2 usage

[Ian Kelly]

On Fri, Mar 30, 2018 at 8:43 PM, Ian Kelly  wrote:
> You really think that 90% of the active users are trolls? And yet the
> subreddit remains usable despite that allegedly terrible
> signal-to-noise ratio.

I'm now laughing at the image of a large community of trolls sitting
around trolling each other and not realizing that they're all being
trolled.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python Developer Survey: Python 3 usage overtakes Python 2 usage

[Ian Kelly]

On Fri, Mar 30, 2018 at 7:10 PM, Rick Johnson
 wrote:
> On Friday, March 30, 2018 at 7:44:40 PM UTC-5, Steven D'Aprano wrote:
> [...]
>> Reddit's /ruby subreddit: 40,571 subscribers.
>>
>> Reddit's /python subreddit: 230,858 subscribers.
>
> Those numbers mean nothing unless you can prove all two-
> hundred-thirty-odd thousand of them to be active, non-
> tolling, non-socking, non-spaming accounts.
>
> Sure, i can imagine Python-list has an impressively large
> number of registered users, however, on a daily basis there
> are only 3-5 on-topic threads. And of those, the majority of
> the posts are send by a hanful of regulars.
>
> IOWs: these "membership numbers" are not true metrics.
>
> I'd wager to say that only a couple hundred accounts out of
> that 230,000 are active and legit python programmers (if
> that).

How about this: at the time of posting, /r/ruby has 69 users here
"now", which Reddit defines as having viewed the subreddit within the
past 15 minutes. /r/python has 509 users here "now".

Scale up to 30DA users and I"m sure the numbers look much larger than
that for each.

You really think that 90% of the active users are trolls? And yet the
subreddit remains usable despite that allegedly terrible
signal-to-noise ratio.

Be realistic, dude.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python Developer Survey: Python 3 usage overtakes Python 2 usage

[Chris Angelico]

On Sat, Mar 31, 2018 at 12:10 PM, Rick Johnson
 wrote:
> On Friday, March 30, 2018 at 7:44:40 PM UTC-5, Steven D'Aprano wrote:
> [...]
>> Reddit's /ruby subreddit: 40,571 subscribers.
>>
>> Reddit's /python subreddit: 230,858 subscribers.
>
> Those numbers mean nothing unless you can prove all two-
> hundred-thirty-odd thousand of them to be active, non-
> tolling, non-socking, non-spaming accounts.
>
> Sure, i can imagine Python-list has an impressively large
> number of registered users, however, on a daily basis there
> are only 3-5 on-topic threads. And of those, the majority of
> the posts are send by a hanful of regulars.
>
> IOWs: these "membership numbers" are not true metrics.
>
> I'd wager to say that only a couple hundred accounts out of
> that 230,000 are active and legit python programmers (if
> that).
>
> Be realistic dude.

You can pooh-pooh any statistic. So far, though, you have provided NO
statistics of your own, just your own gut feeling. Wanna provide some
competing information showing that other languages are more used? No?
A what a terrible pity. I guess it's your gut against lots and
lots of people's real information.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python Developer Survey: Python 3 usage overtakes Python 2 usage

[Rick Johnson]

On Friday, March 30, 2018 at 7:44:40 PM UTC-5, Steven D'Aprano wrote:
[...]
> Reddit's /ruby subreddit: 40,571 subscribers.
>
> Reddit's /python subreddit: 230,858 subscribers.

Those numbers mean nothing unless you can prove all two-
hundred-thirty-odd thousand of them to be active, non-
tolling, non-socking, non-spaming accounts.

Sure, i can imagine Python-list has an impressively large
number of registered users, however, on a daily basis there
are only 3-5 on-topic threads. And of those, the majority of
the posts are send by a hanful of regulars.

IOWs: these "membership numbers" are not true metrics.

I'd wager to say that only a couple hundred accounts out of
that 230,000 are active and legit python programmers (if
that).

Be realistic dude.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python Developer Survey: Python 3 usage overtakes Python 2 usage

[Steven D'Aprano]

On Fri, 30 Mar 2018 16:18:57 -0700, Rick Johnson wrote:

> My suspicion is that not only are the overall numbers of Python
> programmers on the decline

Python's popularity went up from #5 to #4 between March 2017 and 2018 on 
TIOBE: https://www.tiobe.com/tiobe-index/

But of course Rick knows this, and ignores it:

> i pay absolutely zero attention to the TIOBI index


Python's popularity on StackOverflow is also rapidly rising:

https://stackoverflow.blog/2017/09/06/incredible-growth-python/

and according to the article:

"With a 27% year-over year-growth rate, Python stands alone as a tag that 
is *both large and growing rapidly*" (emphasis in the original).

Measuring popularity by google searches not only puts Python at #2 
(behind only Java) but also the most rapidly increasing language:

https://pypl.github.io/PYPL.html

(trend of +5.4% since March 2017 -- the next highest were Typescript and 
R at +0.4% each). Over the last five years, Python's popularity has grown 
the most (12.5%).

RedMonk finds Python at #3 in the first quarter of 2018:

http://redmonk.com/sogrady/2018/03/07/language-rankings-1-18/


This blog post is a few years ago, but it helps show the incredible 
success of Python, not just among students, but also professionals:

https://thenewstack.io/popularity-python-java-world/


Reddit's /ruby subreddit: 40,571 subscribers.

Reddit's /python subreddit: 230,858 subscribers.

Yeah, it's clear that Python is in deep, deep trouble. /sarcasm



-- 
Steve

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python Developer Survey: Python 3 usage overtakes Python 2 usage

[Steven D'Aprano]

On Sat, 31 Mar 2018 00:42:31 +0300, Marko Rauhamaa wrote:

> Paul Rubin :
>> Terry Reedy  writes:
>>> 2017 25% 2.x, 75% 3.x
>>> This is a bigger jump than I anticipated.
>>
>> It's interesting and surprising. I still have not encountered anyone
>> using Python 3 in real life. The main Linux distros still use Python 2
>> by default, afaik. I figured Python 3 adoption would increase if and
>> when that changes.
> 
> Yes, RHEL, CentOS and OracleLinux still only support Python2. It may be
> another year before Python3 becomes available on them.

That's incorrect. RHEL and CentOS support Python 3, as python3. It may 
not be installed by default, but installing it is easy:

yum install python3

ought to work, although it won't give you the latest 3.x. You can also 
install from community repos:

https://janikarhunen.fi/how-to-install-python-3-6-1-on-centos-7.html


or install from source.

OracleLinux, I had no idea that was even a thing until now so I won't 
comment on that.



-- 
Steve

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python Developer Survey: Python 3 usage overtakes Python 2 usage

[Steven D'Aprano]

On Fri, 30 Mar 2018 11:45:10 -0400, Terry Reedy wrote:

> https://www.jetbrains.com/research/python-developers-survey-2017/ “Which
> version of Python do you use the most?” 
> 2014 80% 2.x, 20% 3.x
> 2016 60% 2.x, 40% 3.x
> 2017 25% 2.x, 75% 3.x
> 
> This is a bigger jump than I anticipated.

Thanks for finding the info Terry. It's about what I expected, a typical 
S-shaped adoption curve:

https://en.wikipedia.org/wiki/Sigmoid_function

You start with a few early adopters, which takes a long time to grow, but 
once it hits a certain critical mass of popularity, there is a sudden and 
rapid period of growth until the great majority are using the new 
technology.

According to the standard technology adoption life-cycle, we're now in 
the period where the Late Majority are moving to Python 3. By 2020, I 
expect that will be complete, and we'll enter a long period as the 
Laggards slowly convert over a period of about five years.

https://en.wikipedia.org/wiki/Technology_adoption_life_cycle

https://ondigitalmarketing.com/learn/odm/foundations/5-customer-segments-
technology-adoption/

So I expect that by 2025, the percentage of people using 2.x will drop 
below 1% and by 2030 the numbers using 2.x will be about the same as 
those using 1.x.


-- 
Steve

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python Developer Survey: Python 3 usage overtakes Python 2 usage

[Rick Johnson]

On Friday, March 30, 2018 at 10:45:35 AM UTC-5, Terry Reedy wrote:
> https://www.jetbrains.com/research/python-developers-survey-2017/
> “Which version of Python do you use the most?”
> 2014 80% 2.x, 20% 3.x
> 2016 60% 2.x, 40% 3.x
> 2017 25% 2.x, 75% 3.x
> 
> This is a bigger jump than I anticipated.

If these stats are true, i would caution not to draw any
rash conclusions from them. Even *IF* there are more Python3
programmers today than Python2 (and personally, i'm not
buying it!), what *REALLY* matters is the following:

(1) Has the total number of Python programmers remained
steady? (or has it increased or decreased?)
 
(2) What percentage of the Python3 users are merely students
who use Python (probably against their will) as part of
university studies, and thus, will abandon the language when
(and *IF*) they move into the professional world.

(3) Of the aforementioned students, how many are training to
become actual programmers?

My suspicion is that not only are the overall numbers of
Python programmers on the decline (Thanks, Python3000!),
but the folks who are using Python are mostly students who
will abandon the language when they leave university.

In the end, the property which matters _most_ here is
quaLity not quaNtity. IOWs: a hundred professional grade
softwares in the wild are more important than a billion
hello world programs in the classroom. Which is another
reason why i pay absolutely zero attention to the TIOBI
index (nothin' but hype!).
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python Developer Survey: Python 3 usage overtakes Python 2 usage

[Marko Rauhamaa]

Paul Rubin :
> Terry Reedy  writes:
>> 2017 25% 2.x, 75% 3.x
>> This is a bigger jump than I anticipated.
>
> It's interesting and surprising. I still have not encountered anyone
> using Python 3 in real life. The main Linux distros still use Python 2
> by default, afaik. I figured Python 3 adoption would increase if and
> when that changes.

Yes, RHEL, CentOS and OracleLinux still only support Python2. It may be
another year before Python3 becomes available on them.

Also, MacOS comes with Python2.

> I'll have to get on the boat sometime, but so far have mostly avoided
> it.

I use Python3 wherever I can, but most stuff must still stay with
Python2.


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python Developer Survey: Python 3 usage overtakes Python 2 usage

[Paul Moore]

On 30 March 2018 at 16:45, Terry Reedy  wrote:
> https://www.jetbrains.com/research/python-developers-survey-2017/
> “Which version of Python do you use the most?”
> 2014 80% 2.x, 20% 3.x
> 2016 60% 2.x, 40% 3.x
> 2017 25% 2.x, 75% 3.x
>
> This is a bigger jump than I anticipated.

Nice!
-- 
https://mail.python.org/mailman/listinfo/python-list

Python Developer Survey: Python 3 usage overtakes Python 2 usage

[Terry Reedy]

https://www.jetbrains.com/research/python-developers-survey-2017/
“Which version of Python do you use the most?”
2014 80% 2.x, 20% 3.x
2016 60% 2.x, 40% 3.x
2017 25% 2.x, 75% 3.x

This is a bigger jump than I anticipated.

--
Terry Jan Reedy


--
https://mail.python.org/mailman/listinfo/python-list

Platform preferences survey (your chance to gripe about app stores!)

[Zak Fenton]

Hi everyone!


I'm launching a business offering new tools and services that might be of 
interest to users of scripting languages, so I'm interested in hearing your 
input (again).


Thanks to those of you who participated in the earlier survey I've been busy 
improving the product suite to better match the needs of the community, so now 
I'm looking for more information about platform and distribution preferences in 
the lead-up to release. (Those of you who opted in for the beta trial are still 
on the list, I'll be in touch soon.)


This survey should take less than 4 minutes to complete:

https://www.surveymonkey.com/r/JBGCHZR


Thanks!


-Zak.

-- 
https://mail.python.org/mailman/listinfo/python-list

Survey results: How software ecosystems deal with breaking changes

[Chris Bogart]

 Last fall we announced on this list a survey about how and why breaking
changes are handled differently in 18 different software ecosystems.  We've
just submitted a paper to a conference about the results, and we've also
set up a site (http://breakingapis.org/survey) where you can compare how
different ecosystems perceived their values, practices of upstream and
downstream developers, and the health of their ecosystem.

Results showed some stark differences between software communities, for
example: Making updates available to end users quickly was highly valued by
Node and Ruby communities, but was considered less important to Eclipse. (
http://breakingapis.org/survey/values.html#rapid?ecos=Haskell_Stack_Stackage_,Node_js_NPM,Ruby_Rubygems)
The
Perl and Eclipse communities value stability most, while Hackage/Cabal
valued it least. (
http://breakingapis.org/survey/values.html#stability?ecos=Eclipse_plugins_,Haskell_Cabal_Hackage_,Perl_CPAN
)

Ecosystems have very different ways of dealing with versioning; for example
in Go it's common for people to sometimes make small updates without
increasing the version number. (
http://breakingapis.org/survey/upstream.html#mon_versionless_updates_eco?ecos=Go,Maven,Node_js_NPM)
 In Rust, developers more frequently chip in and help with maintenance of
upstream packages than in NuGet.(
http://breakingapis.org/survey/downstream.html#sync_liaison_code?ecos=NuGet,Rust_Cargo)


There are a lot of other results on the linked site, and we’re interested
in your impressions of the results.  Do the results make sense to
you?  What answers would you have expected?  Do you think the differences
are intentional?  If you have any thoughts about it I’ll try to keep up
with comments here, or you can also send us comments through the website.
The anonymized raw data  is also available here:
https://doi.org/10.1184/R1/5108716

We want to sincerely thank the large number of people in the Python
community who responded, and we’re eager to hear what you think!

Chris, Anna, Jim, and Christian
-- 
https://mail.python.org/mailman/listinfo/python-list

Free Beta Invite for new scripting/VM technology (some survey answers required)

[Zak Fenton]

Hi everyone!


I'm in the process of launching a business around a new scripting-related 
technology. It's not specific to Python users, but may be of interest to many 
of you, so I'd like to make sure Python users are represented in my initial 
market research.


It's a very short survey and should take less than five minutes to complete. In 
return, you'll get a chance to play with the first beta release as it becomes 
available over the coming months (however places in the beta program are 
limited, so availability cannot be guaranteed).


The survey is here (the last page allows you to opt in to the beta program):


https://www.surveymonkey.com/r/HTLLWTB


Thanks,

-Zak.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Survey: improving the Python std lib docs

[rzed]

A portion of this thread seems to be focusing on what key word args parameters 
actually mean, in the Python sense. There is documentation for that, and a 
modicum of experience with Python makes this a relatively simple question and 
answer. However, when docs for a specific function or method specify keyword 
arguments without any indication of what the *expected* arguments might be, or 
what *useful* arguments might be, then it's not really helpful. If I have to 
look at the source code to figure out how the args are used, I don't need the 
docs at all. Which is why I suggest a line or two with sample invocations to 
provide at least a starting point to understand the parameters. 

A doc signature that says something like "do_something(p1, d)" tells me very 
little. Even knowing that p1 is a "Point" is not all that valuable, except to 
give me another item to look up (the expected Point implementation). However, 
an example like 'do_something((141,380),"January, 2017")' tells me a lot more - 
that the Point is actually a tuple with (probably) x-y coordinates, and 'd' is 
a description associated with that position. That's a lot of useful information 
at a cost of a couple of dozen characters. So why not add a few examples? 
-- 
https://mail.python.org/mailman/listinfo/python-list

RE: Survey: improving the Python std lib docs

[Deborah Swanson]

> -Original Message-
> From: Python-list 
> [mailto:python-list-bounces+python=deborahswanson.net@python.o
> rg] On Behalf Of Gregory Ewing
> Sent: Thursday, May 18, 2017 5:00 PM
> To: python-list@python.org
> Subject: Re: Survey: improving the Python std lib docs
> 
> 
> Deborah Swanson wrote:
> 
> > somenamedtuple._replace(kwargs)
> > 
> > Return a new instance of the named tuple replacing specified 
> > fields with new values: (Examples
> > box)---|
> > |>>>
> > |
> > |
> > |
> > |>>> p = Point(x=11, y=22)
> > |
> > |>>> p._replace(x=33)
> > |
> > |Point(x=33, y=22)
> 
> To someone who has some basic Python knowledge about what 
> keyword arguments are, that's actually pretty clear. What 
> it's saying is that any of the namedtuple's attribute names 
> can be used as a keyword argument to the _replace method.
> 
> Namedtuple is something of a special case, because it doesn't 
> have a fixed set of acceptable keyword args. Most things do, 
> and there should be something somewhere in the docs 
> indicating what they are. Note that you may need to consult 
> docs for base classes to get the full picture, since e.g. 
> constructors often pass any keyword args they don't 
> understand on to their base class constructor.

I'm getting a clearer picture, and even though it might not be as
cleanly straightforward as using recordsclass, I think it would be a
good learning experience to use "somenamedtuple._replace(kwargs)" in a
context of my own devising, rather than just copying out code given for
a different problem from someone else.

Besides, I need to compile memoryslots.c to make a usable recordsclass
module, and I haven't successfully compiled a C program outside of
Visual Studio yet(and that was a couple decades ago). So I'm going to
see if I can really understand kwargs in a namedtuple context first.  

It will be good to have a bag of tricks to tackle all my Excel
spreadsheet conversion-to-Python and new-from-scratch projects with. I'm
saying goodbye to Microsoft Excel, but I want to take all my work and
ideas with me. And who knows, maybe I'll have some templates and
tutorials to contribute for others who'd like to do the same.

> > Now, I understood what he meant from the context of the problem he
was 
> > helping me with, but, how in the world would I have gotten that 
> > possible use of somenamedtuple._replace(kwargs) from the blurb and 
> > examples in the docs?
> 
>  From knowledge about keyword arguments in general, 
> exrapolation from the example, and following logic.
> 
> I know that's probably not a very helpful answer, but the 
> reason it seems so obscure to you now is because you don't 
> have all of the basic Python knowledge that the docs assume 
> the reader has. If you come back to the same docs later when 
> you do have that knowledge, you will see it all more clearly.

Oh, I think I see what you mean now. But I'm sure glad I've had this
list to talk to, or I'd never have figured it out from scratch on my
own.

> > If there's a tutorial somewhere on kwargs in general, what specific 
> > types of kwargs there are, what special operators can be specifed
for 
> > them and how the kwargs are used, it would be very helpful to have 
> > that tutorial referenced in a footnote-link next to kwargs whenever 
> > kwargs is part of a function specification.
> 
> This is all general knowlege about the Python language that 
> you can't expect the reference documentation to point out in 
> relation to every function and method.

No, perhaps not. I was frustrated by not being able to see and
understand what I needed to know from the docs, but maybe more in depth
tutorials for beginners, and some kind of pointers to them, would fill
that gap more effectively.
 
> > I have an item on my todo list to google "python kwargs", but it
keeps 
> > getting pushed deeper and deeper down my list because I have so
little 
> > hope that it will turn up anything useful.
> 
> I strongly encourage you to do it sooner rather than later, 
> because you'll gain some important foundational knowledge 
> that's vital for understanding many things you'll see in 
> Python code and Python docs.
> 
> -- 
> Greg

I may do that Google search when I get to it, but I've learned a lot
right here. Maybe enough, but Ill have to work with what I now know to
see that.

Thanks very much,

Deborah

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Survey: improving the Python std lib docs

[Gregory Ewing]

Deborah Swanson wrote:


somenamedtuple._replace(kwargs)

Return a new instance of the named tuple replacing specified fields
with new values:
(Examples
box)---|
|>>>
|
|
|
|>>> p = Point(x=11, y=22)
|
|>>> p._replace(x=33)
|
|Point(x=33, y=22)


To someone who has some basic Python knowledge about what keyword
arguments are, that's actually pretty clear. What it's saying is
that any of the namedtuple's attribute names can be used as a
keyword argument to the _replace method.

Namedtuple is something of a special case, because it doesn't have a
fixed set of acceptable keyword args. Most things do, and there should
be something somewhere in the docs indicating what they are. Note
that you may need to consult docs for base classes to get the full
picture, since e.g. constructors often pass any keyword args they
don't understand on to their base class constructor.


Now, I understood what he meant from the context of the problem he was
helping me with, but, how in the world would I have gotten that possible
use of somenamedtuple._replace(kwargs) from the blurb and examples in
the docs?


From knowledge about keyword arguments in general, exrapolation
from the example, and following logic.

I know that's probably not a very helpful answer, but the reason
it seems so obscure to you now is because you don't have all of
the basic Python knowledge that the docs assume the reader has.
If you come back to the same docs later when you do have that
knowledge, you will see it all more clearly.


If there's a tutorial somewhere on kwargs in general, what specific
types of kwargs there are, what special operators can be specifed for
them and how the kwargs are used, it would be very helpful to have that
tutorial referenced in a footnote-link next to kwargs whenever kwargs is
part of a function specification.


This is all general knowlege about the Python language that you
can't expect the reference documentation to point out in relation
to every function and method.


I have an item on my todo list to google "python kwargs", but it keeps
getting pushed deeper and deeper down my list because I have so little
hope that it will turn up anything useful.


I strongly encourage you to do it sooner rather than later, because
you'll gain some important foundational knowledge that's vital for
understanding many things you'll see in Python code and Python docs.

--
Greg
--
https://mail.python.org/mailman/listinfo/python-list

RE: Survey: improving the Python std lib docs

[Deborah Swanson]

justin walters wrote, on Thursday, May 18, 2017 8:09 AM
> To: python-list@python.org
> Subject: Re: Survey: improving the Python std lib docs
> 
> So, args can be treated as a simple (named)? tuple or a 
> simple dictionary. `*` unpacks a list or tuple and `**` 
> unpacks a dictionary. I'm sure it's a lot more nuanced than 
> this, but for practical reasons, the above explanation has 
> never failed me.
> 
> I hope I didn't miss the entire point of the thread. Someone 
> needed help with `**kwargs` right?

I think I was mainly the one who wasn't sure what "**kwargs" are, and
this, plus your examples I snipped, and bits and pieces I already knew,
neatly pulls it all together.

Think I have a good working idea of it now, so thanks!

Deborah

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Survey: improving the Python std lib docs

[justin walters]

On Thu, May 18, 2017 at 8:08 AM, justin walters 
wrote:

>
>
> On Thu, May 18, 2017 at 12:09 AM, Deborah Swanson <
> pyt...@deborahswanson.net> wrote:
>
>> Michael Torrie wrote, on Wednesday, May 17, 2017 3:11 PM
>> >
>> > On 05/17/2017 02:31 PM, Ned Batchelder wrote:
>> > > Can you give an example of such a method? Often, that signature is
>> > > used because there is no pre-conception of what the arguments might
>> > > be.
>> >
>> > I'm not sure if this afflicts the standard library, but in my
>> > own code, since Python doesn't support constructors with
>> > different signatures, you pretty much have to rely on kwargs
>> > with __init__() to handle different permutations of
>> > construction arguments.  Not that we don't know what the
>> > arguments might be, we just don't know which of them we'll
>> > have to deal with.  Maybe the standard library is better
>> > designed than my own code, but I find I have to implement
>> > __init__(self, **kwargs) all the time.
>>
>>
>> While I can respect and appreciate your specialized interest in specific
>> kwargs, and I read in other's posts that help()'s display of kwargs is
>> conditional on several things, I really want to reiterate and clarify my
>> beginner's request.
>>
>> I know of several functions I've used without any *args or **kwargs
>> because I had no clue from the docs what they might be. And, I know of
>> one function now, from posts in this list, which takes kwargs, but I
>> only know one application of one possible kwarg in this function because
>> one member of this list, Peter Otten, used it in a suggestion he gave
>> me.
>>
>> This is all there is in the docs for that function:
>>
>>
>> somenamedtuple._replace(kwargs)
>>
>> Return a new instance of the named tuple replacing specified fields
>> with new values:
>> (Examples
>> box)---|
>> |>>>
>> |
>> |
>> |
>> |>>> p = Point(x=11, y=22)
>> |
>> |>>> p._replace(x=33)
>> |
>> |Point(x=33, y=22)
>> |
>> |
>> |
>> |>>> for partnum, record in inventory.items():
>> |
>> |... inventory[partnum] =
>> record._replace(price=newprices[partnum], |
>> |  timestamp=time.now())
>> |
>> |---
>> |
>>
>> From this doc entry's example, I (sort of) get that x is a keyword arg
>> that is to be equal to 33 for any use of p._replace() in the code
>> following, until
>> p._replace(kwarg) is respecified, or the code ends. So the response from
>> Python shows me that p has transformed to the Point(x=33, y=22). A
>> trivial example that doesn't begin to hint at the poential powers of
>> this kwarg.
>>
>> The inventory[partnum] example is also quite trivial compared to the
>> kwarg use that Peter showed me.
>>
>> When I asked him for an explanation, this is what I and he he said:
>>
>> Deborah Swanson wrote:
>>
>> > I know it's your "ugly" answer, but can I ask what the '**' in
>> >
>> > fix = {label: max(values, key=len)}
>> > group[:] = [record._replace(**fix) for record in group]
>> >
>> > means?
>>
>> (Peter wrote)
>> d = {"a": 1, "b": 2}
>> f(**d)
>>
>> is equivalent to
>>
>> f(a=1, b=2)
>>
>> so ** is a means to call a function with keyword arguments when you want
>> to
>> decide about the *names* at runtime. Example:
>>
>> >>> def f(a=1, b=2):
>> ... print("a =", a)
>> ... print("b =", b)
>> ... print()
>> ...
>> >>> for d in [{"a": 10}, {"b": 42}, {"a": 100, "b": 200}]:
>> ... f(**d)
>> ...
>> a = 10
>> b = 2
>>
>> a = 1
>> b = 42
>>
>> a = 100
>> b = 200
>>
>> Starting from a namedtuple `record`
>>
>> record._replace(Location="elswhere")
>>
>> creates a new namedtuple with the Location attribute changed to
>> "elsewhere",
>> and the slice [:] on the left causes all items in the `groups` list to
>> be
>> replaced with new namedtuples,
>>
>> group[:] = [record._replace(Location="elsewhere") for record in group]
>>
>> is basically the same as
>>
>> tmp = group.copy()
>> group.clear()
>> for record in tmp:
>> group.append(record_replace(Location="elsewhere"))
>>
>> To support not just Location, but also Kind and Notes we need the double
>>
>> asterisk.
>>
>>
>>
>> Now, I understood what he meant from the context of the problem he was
>> helping me with, but, how in the world would I have gotten that possible
>> use of somenamedtuple._replace(kwargs) from the blurb and examples in
>> the docs? Or any other possible kwarg and how they're used, including
>> special operators like "**" ?
>>
>> If there's a tutorial somewhere on kwargs in general, what specific
>> types of kwargs there are, what special operators can be specifed for
>> them and how the kwargs are used, it would be very helpful to have that
>> tutorial referenced in a footnote-link next to kwargs whenever kwargs is
>> part of a function specification.
>>
>> Or, if no such tutorial exists, the footnote-link could point to any
>> more detailed information that might explain w

Re: Survey: improving the Python std lib docs

[justin walters]

On Thu, May 18, 2017 at 12:09 AM, Deborah Swanson  wrote:

> Michael Torrie wrote, on Wednesday, May 17, 2017 3:11 PM
> >
> > On 05/17/2017 02:31 PM, Ned Batchelder wrote:
> > > Can you give an example of such a method? Often, that signature is
> > > used because there is no pre-conception of what the arguments might
> > > be.
> >
> > I'm not sure if this afflicts the standard library, but in my
> > own code, since Python doesn't support constructors with
> > different signatures, you pretty much have to rely on kwargs
> > with __init__() to handle different permutations of
> > construction arguments.  Not that we don't know what the
> > arguments might be, we just don't know which of them we'll
> > have to deal with.  Maybe the standard library is better
> > designed than my own code, but I find I have to implement
> > __init__(self, **kwargs) all the time.
>
>
> While I can respect and appreciate your specialized interest in specific
> kwargs, and I read in other's posts that help()'s display of kwargs is
> conditional on several things, I really want to reiterate and clarify my
> beginner's request.
>
> I know of several functions I've used without any *args or **kwargs
> because I had no clue from the docs what they might be. And, I know of
> one function now, from posts in this list, which takes kwargs, but I
> only know one application of one possible kwarg in this function because
> one member of this list, Peter Otten, used it in a suggestion he gave
> me.
>
> This is all there is in the docs for that function:
>
>
> somenamedtuple._replace(kwargs)
>
> Return a new instance of the named tuple replacing specified fields
> with new values:
> (Examples
> box)---|
> |>>>
> |
> |
> |
> |>>> p = Point(x=11, y=22)
> |
> |>>> p._replace(x=33)
> |
> |Point(x=33, y=22)
> |
> |
> |
> |>>> for partnum, record in inventory.items():
> |
> |... inventory[partnum] =
> record._replace(price=newprices[partnum], |
> |  timestamp=time.now())
> |
> |---
> |
>
> From this doc entry's example, I (sort of) get that x is a keyword arg
> that is to be equal to 33 for any use of p._replace() in the code
> following, until
> p._replace(kwarg) is respecified, or the code ends. So the response from
> Python shows me that p has transformed to the Point(x=33, y=22). A
> trivial example that doesn't begin to hint at the poential powers of
> this kwarg.
>
> The inventory[partnum] example is also quite trivial compared to the
> kwarg use that Peter showed me.
>
> When I asked him for an explanation, this is what I and he he said:
>
> Deborah Swanson wrote:
>
> > I know it's your "ugly" answer, but can I ask what the '**' in
> >
> > fix = {label: max(values, key=len)}
> > group[:] = [record._replace(**fix) for record in group]
> >
> > means?
>
> (Peter wrote)
> d = {"a": 1, "b": 2}
> f(**d)
>
> is equivalent to
>
> f(a=1, b=2)
>
> so ** is a means to call a function with keyword arguments when you want
> to
> decide about the *names* at runtime. Example:
>
> >>> def f(a=1, b=2):
> ... print("a =", a)
> ... print("b =", b)
> ... print()
> ...
> >>> for d in [{"a": 10}, {"b": 42}, {"a": 100, "b": 200}]:
> ... f(**d)
> ...
> a = 10
> b = 2
>
> a = 1
> b = 42
>
> a = 100
> b = 200
>
> Starting from a namedtuple `record`
>
> record._replace(Location="elswhere")
>
> creates a new namedtuple with the Location attribute changed to
> "elsewhere",
> and the slice [:] on the left causes all items in the `groups` list to
> be
> replaced with new namedtuples,
>
> group[:] = [record._replace(Location="elsewhere") for record in group]
>
> is basically the same as
>
> tmp = group.copy()
> group.clear()
> for record in tmp:
> group.append(record_replace(Location="elsewhere"))
>
> To support not just Location, but also Kind and Notes we need the double
>
> asterisk.
>
>
>
> Now, I understood what he meant from the context of the problem he was
> helping me with, but, how in the world would I have gotten that possible
> use of somenamedtuple._replace(kwargs) from the blurb and examples in
> the docs? Or any other possible kwarg and how they're used, including
> special operators like "**" ?
>
> If there's a tutorial somewhere on kwargs in general, what specific
> types of kwargs there are, what special operators can be specifed for
> them and how the kwargs are used, it would be very helpful to have that
> tutorial referenced in a footnote-link next to kwargs whenever kwargs is
> part of a function specification.
>
> Or, if no such tutorial exists, the footnote-link could point to any
> more detailed information that might explain what this creature "kwargs"
> might be.
>
> I have an item on my todo list to google "python kwargs", but it keeps
> getting pushed deeper and deeper down my list because I have so little
> hope that it will turn up anything useful.
>
> Deborah

RE: Survey: improving the Python std lib docs

[Deborah Swanson]

Michael Torrie wrote, on Wednesday, May 17, 2017 3:11 PM
> 
> On 05/17/2017 02:31 PM, Ned Batchelder wrote:
> > Can you give an example of such a method? Often, that signature is 
> > used because there is no pre-conception of what the arguments might 
> > be.
> 
> I'm not sure if this afflicts the standard library, but in my 
> own code, since Python doesn't support constructors with 
> different signatures, you pretty much have to rely on kwargs 
> with __init__() to handle different permutations of 
> construction arguments.  Not that we don't know what the 
> arguments might be, we just don't know which of them we'll 
> have to deal with.  Maybe the standard library is better 
> designed than my own code, but I find I have to implement 
> __init__(self, **kwargs) all the time.


While I can respect and appreciate your specialized interest in specific
kwargs, and I read in other's posts that help()'s display of kwargs is
conditional on several things, I really want to reiterate and clarify my
beginner's request.

I know of several functions I've used without any *args or **kwargs
because I had no clue from the docs what they might be. And, I know of
one function now, from posts in this list, which takes kwargs, but I
only know one application of one possible kwarg in this function because
one member of this list, Peter Otten, used it in a suggestion he gave
me.

This is all there is in the docs for that function:


somenamedtuple._replace(kwargs)

Return a new instance of the named tuple replacing specified fields
with new values:
(Examples
box)---|
|>>>
|
|
|
|>>> p = Point(x=11, y=22)
|
|>>> p._replace(x=33)
|
|Point(x=33, y=22)
|
|
|
|>>> for partnum, record in inventory.items():
|
|... inventory[partnum] =
record._replace(price=newprices[partnum], |
|  timestamp=time.now())
|
|---
|

>From this doc entry's example, I (sort of) get that x is a keyword arg
that is to be equal to 33 for any use of p._replace() in the code
following, until 
p._replace(kwarg) is respecified, or the code ends. So the response from
Python shows me that p has transformed to the Point(x=33, y=22). A
trivial example that doesn't begin to hint at the poential powers of
this kwarg.

The inventory[partnum] example is also quite trivial compared to the
kwarg use that Peter showed me.

When I asked him for an explanation, this is what I and he he said:

Deborah Swanson wrote:

> I know it's your "ugly" answer, but can I ask what the '**' in
> 
> fix = {label: max(values, key=len)}
> group[:] = [record._replace(**fix) for record in group]
> 
> means?

(Peter wrote)
d = {"a": 1, "b": 2}
f(**d)

is equivalent to

f(a=1, b=2)

so ** is a means to call a function with keyword arguments when you want
to 
decide about the *names* at runtime. Example:

>>> def f(a=1, b=2):
... print("a =", a)
... print("b =", b)
... print()
... 
>>> for d in [{"a": 10}, {"b": 42}, {"a": 100, "b": 200}]:
... f(**d)
... 
a = 10
b = 2

a = 1
b = 42

a = 100
b = 200

Starting from a namedtuple `record`

record._replace(Location="elswhere")

creates a new namedtuple with the Location attribute changed to
"elsewhere", 
and the slice [:] on the left causes all items in the `groups` list to
be 
replaced with new namedtuples,

group[:] = [record._replace(Location="elsewhere") for record in group]

is basically the same as

tmp = group.copy()
group.clear()
for record in tmp:
group.append(record_replace(Location="elsewhere"))

To support not just Location, but also Kind and Notes we need the double

asterisk.



Now, I understood what he meant from the context of the problem he was
helping me with, but, how in the world would I have gotten that possible
use of somenamedtuple._replace(kwargs) from the blurb and examples in
the docs? Or any other possible kwarg and how they're used, including
special operators like "**" ?

If there's a tutorial somewhere on kwargs in general, what specific
types of kwargs there are, what special operators can be specifed for
them and how the kwargs are used, it would be very helpful to have that
tutorial referenced in a footnote-link next to kwargs whenever kwargs is
part of a function specification.

Or, if no such tutorial exists, the footnote-link could point to any
more detailed information that might explain what this creature "kwargs"
might be.

I have an item on my todo list to google "python kwargs", but it keeps
getting pushed deeper and deeper down my list because I have so little
hope that it will turn up anything useful.

Deborah

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Survey: improving the Python std lib docs

[Chris Angelico]

On Thu, May 18, 2017 at 8:11 AM, Michael Torrie  wrote:
> On 05/17/2017 02:31 PM, Ned Batchelder wrote:
>> Can you give an example of such a method? Often, that signature is used
>> because there is no pre-conception of what the arguments might be.
>
> I'm not sure if this afflicts the standard library, but in my own code,
> since Python doesn't support constructors with different signatures, you
> pretty much have to rely on kwargs with __init__() to handle different
> permutations of construction arguments.  Not that we don't know what the
> arguments might be, we just don't know which of them we'll have to deal
> with.  Maybe the standard library is better designed than my own code,
> but I find I have to implement __init__(self, **kwargs) all the time.

Also worth noting is that decorators sometimes have to go *a,**kw on
their functions. Until a couple of versions ago, help() would always
just show *a,**kw, but now there's a protocol between
functools.wraps() and help() that carries the original signature
through. Depending on exactly where you're viewing the info, eg
whether it uses inspect.getsignature or not, you might see the carried
original, or you might see *a,**kw.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Survey: improving the Python std lib docs

[Michael Torrie]

On 05/17/2017 02:31 PM, Ned Batchelder wrote:
> Can you give an example of such a method? Often, that signature is used
> because there is no pre-conception of what the arguments might be.

I'm not sure if this afflicts the standard library, but in my own code,
since Python doesn't support constructors with different signatures, you
pretty much have to rely on kwargs with __init__() to handle different
permutations of construction arguments.  Not that we don't know what the
arguments might be, we just don't know which of them we'll have to deal
with.  Maybe the standard library is better designed than my own code,
but I find I have to implement __init__(self, **kwargs) all the time.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Survey: improving the Python std lib docs

[Ned Batchelder]

On Wednesday, May 17, 2017 at 5:48:30 AM UTC-4, Cem Karan wrote:
> On May 16, 2017, at 12:36 PM, rzed  wrote:
> 
> > On Friday, May 12, 2017 at 6:02:58 AM UTC-4, Steve D'Aprano wrote:
> >> One of the more controversial aspects of the Python ecosystem is the Python
> >> docs. Some people love them, and some people hate them and describe them as
> >> horrible.
> >> 
> > [...]
> > 
> > One thing I would love to see in any function or class docs is a few 
> > example invocations, preferably non-trivial. If I need to see more, I can 
> > read the entire doc, but most times I just want a refresher on how the 
> > function is called. Does it use keywords? Are there required nameless 
> > parameters? In what order? A line or two would immediately clarify that 
> > most of the time. 
> > 
> > Apart from that, links to docs for uncommon functions (or to the docs of 
> > the module, if there are many) would be at least somewhat useful.
> 
> I'd like to see complete signatures in the docstrings, so when I use help() 
> on something that has *args or **kwargs I can see what the arguments actually 
> are.


Can you give an example of such a method? Often, that signature is used
because there is no pre-conception of what the arguments might be.

--Ned.
-- 
https://mail.python.org/mailman/listinfo/python-list

RE: Survey: improving the Python std lib docs

[Deborah Swanson]

Cem Karan wrote, on Wednesday, May 17, 2017 2:48 AM
> 
> On May 16, 2017, at 12:36 PM, rzed  wrote:
> 
> > On Friday, May 12, 2017 at 6:02:58 AM UTC-4, Steve D'Aprano wrote:
> >> One of the more controversial aspects of the Python 
> ecosystem is the 
> >> Python docs. Some people love them, and some people hate them and 
> >> describe them as horrible.
> >> 
> > [...]
> > 
> > One thing I would love to see in any function or class docs is a few

> > example invocations, preferably non-trivial. If I need to 
> see more, I can read the entire doc, but most times I just 
> want a refresher on how the function is called. Does it use 
> keywords? Are there required nameless parameters? In what 
> order? A line or two would immediately clarify that most of the time.
> > 
> > Apart from that, links to docs for uncommon functions (or 
> to the docs 
> > of the module, if there are many) would be at least somewhat useful.
> 
> I'd like to see complete signatures in the docstrings, so 
> when I use help() on something that has *args or **kwargs I 
> can see what the arguments actually are.
> 
> Thanks,
> Cem Karan

I'd also like to see all of the above, especially what the possible
*args or **kwargs are.

Sure hope someone who might do these things is reading this.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Survey: improving the Python std lib docs

[Cem Karan]

On May 16, 2017, at 12:36 PM, rzed  wrote:

> On Friday, May 12, 2017 at 6:02:58 AM UTC-4, Steve D'Aprano wrote:
>> One of the more controversial aspects of the Python ecosystem is the Python
>> docs. Some people love them, and some people hate them and describe them as
>> horrible.
>> 
> [...]
> 
> One thing I would love to see in any function or class docs is a few example 
> invocations, preferably non-trivial. If I need to see more, I can read the 
> entire doc, but most times I just want a refresher on how the function is 
> called. Does it use keywords? Are there required nameless parameters? In what 
> order? A line or two would immediately clarify that most of the time. 
> 
> Apart from that, links to docs for uncommon functions (or to the docs of the 
> module, if there are many) would be at least somewhat useful.

I'd like to see complete signatures in the docstrings, so when I use help() on 
something that has *args or **kwargs I can see what the arguments actually are.

Thanks,
Cem Karan
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Survey: improving the Python std lib docs

[rzed]

On Friday, May 12, 2017 at 6:02:58 AM UTC-4, Steve D'Aprano wrote:
> One of the more controversial aspects of the Python ecosystem is the Python
> docs. Some people love them, and some people hate them and describe them as
> horrible.
> 
[...]

One thing I would love to see in any function or class docs is a few example 
invocations, preferably non-trivial. If I need to see more, I can read the 
entire doc, but most times I just want a refresher on how the function is 
called. Does it use keywords? Are there required nameless parameters? In what 
order? A line or two would immediately clarify that most of the time. 

Apart from that, links to docs for uncommon functions (or to the docs of the 
module, if there are many) would be at least somewhat useful. 

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Survey: improving the Python std lib docs

[Marco Buttu]

On 15/05/2017 13:44, Ned Batchelder wrote:


As it is, if I make a suggestion about the itertools docs (why do we need
20-line "equivalent to" Python code, and why don't we have any usage
examples?), then I have to debate it with the developer of itertools,
who has a different aesthetic and style than the developer of logging,
or email, or re, and so on.


True story


If we had one person who had the authority to make doc-wide decisions,
then we might be able to move towards coherent guidelines for the docs
to be more uniform.


That could be a solution :-)

--
Marco Buttu

INAF-Osservatorio Astronomico di Cagliari
Via della Scienza n. 5, 09047 Selargius (CA)
Phone: 070 711 80 217
Email: mbu...@oa-cagliari.inaf.it

--
https://mail.python.org/mailman/listinfo/python-list

Re: Survey: improving the Python std lib docs

[Ned Batchelder]

On Friday, May 12, 2017 at 6:02:58 AM UTC-4, Steve D'Aprano wrote:
> One of the more controversial aspects of the Python ecosystem is the Python
> docs. Some people love them, and some people hate them and describe them as
> horrible.
> 

I have a number of ideas for improving the docs, but I think there is a
larger issue that needs to be addressed first: there is no BDFL for the
docs. They are written and maintained piecemeal, by the core dev that
wrote the code. If one documentation-focused person had decision-making
power over all the docs, then we might be able to get some consistency
throughout.

As it is, if I make a suggestion about the itertools docs (why do we need
20-line "equivalent to" Python code, and why don't we have any usage
examples?), then I have to debate it with the developer of itertools,
who has a different aesthetic and style than the developer of logging,
or email, or re, and so on.

If we had one person who had the authority to make doc-wide decisions,
then we might be able to move towards coherent guidelines for the docs
to be more uniform.

--Ned.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Survey: improving the Python std lib docs

[jeanbigboute]

On Saturday, May 13, 2017 at 3:39:52 PM UTC-7, Terry Reedy wrote:
> On 5/13/2017 1:23 PM, jeanbigbo...@gmail.com wrote:
> 
> > Thank you for bringing up this important topic.  As an occasional Python 
> > user, I find that Python documentation is all over the usability map - some 
> > great, some difficult.  The Python docs have been at best a starting point. 
> >  I usually need to go to other sites like this group, StackOverflow, and a 
> > blog or two to understand how to do something.  After I learn to do that 
> > one thing, I am not any more independent, self-reliant, or able to 
> > contribute back to the community.  Although Matlab gets a lot of grief in 
> > the open source community, its documentation is concise, complete, and 
> > self-contained.
> 
> Thank you for writing a response focused on your experience with the docs.

... [ trimmed ] ...

I appreciate your prompt reply.  I would like to 'aggregate' my thoughts along 
a couple of items you mentioned.

1) Old documentation (e.g. Classes referencing Modula-3) and opening trackers.

The Classes and Pkgutil docs are representative of a lot of the Python docs 
that fall into the hard-to-use category.  I would have to file many trackers to 
cover problems I have had.  That's not very grateful in context of an open 
source tool.  Discussing this at a top-level as we are doing here I think is 
fair game.  This is something that needs to be addressed comprehensively or 
possibly intentionally left alone.

If the original doc suite was written 20 years ago, it may not be possible or 
practical to get it caught up when the language evolves so quickly.  
The right answer might be to "leave it be" and accept that newer methods of Q&A 
have to take over.  This is true even of some paid packages - to get help with 
Microsoft, avoid the documentation wherever possible.  This approach has its 
problems especially for corporate users.  They're often behind firewalls and 
can't participate.

2) The blog post:  I think the post author's attempt was a good, honest try and 
an example of what the documentation suite might become.  I agree it is hard to 
come up with good, tested examples across multiple platforms and that's where 
some paid packages have an advantage.  I think the Python community could go a 
little easier on non-free tools.  Trying things and seeing what works is good 
in many cases but there isn't the time for that in a lot of workplaces, 
especially those that bill services by the hour.

--- JBB
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Survey: improving the Python std lib docs

[Terry Reedy]

On 5/13/2017 1:23 PM, jeanbigbo...@gmail.com wrote:


Thank you for bringing up this important topic.  As an occasional Python user, 
I find that Python documentation is all over the usability map - some great, 
some difficult.  The Python docs have been at best a starting point.  I usually 
need to go to other sites like this group, StackOverflow, and a blog or two to 
understand how to do something.  After I learn to do that one thing, I am not 
any more independent, self-reliant, or able to contribute back to the 
community.  Although Matlab gets a lot of grief in the open source community, 
its documentation is concise, complete, and self-contained.


Thank you for writing a response focused on your experience with the docs.


A table of functions/classes at the start of a Python doc would be very 
helpful.  I'd also like to see a tree-like overview of a package so I can get 
an idea of what's available and how deep the dot-indexed hierarchy goes.  I've 
tried to write code to extract/present this for myself and have failed.  IDEs 
and Notebooks allow descending a branch one dot at a time - very time consuming.

Many of the docs go deep into CS terminology from the start which can be 
daunting. Here's the first paragraph from the 'Classes' documentation:
https://docs.python.org/2/tutorial/classes.html


The tutorial is meant to be for 'beginners'.


"Compared with other programming languages, Python’s class mechanism adds classes 
with a minimum of new syntax and semantics. It is a mixture of the class mechanisms found 
in C++ and Modula-3. Python classes provide all the standard features of Object Oriented 
Programming: the class inheritance mechanism allows multiple base classes, a derived 
class can override any methods of its base class or classes, and a method can call the 
method of a base class with the same name."

I am sure it is all correct.  I just don't know what it means.


When that was likely written, more that two decades ago, python 
beginners were experienced programmers who would have known much of the 
above.  Python beginners today are much different (and even experienced 
programmers are unlikely to know anything about Modula-x.)


If you would like it changed, open an issue on the tracker.


I saw pkgutil referenced in answers to some StackOverflow questions and I 
looked into it:

https://docs.python.org/2/library/pkgutil.html

"This module provides utilities for the import system, in particular package 
support."

Then it gets very specialized.

I am well aware of the distinction between documentation and tutorials. I think 
that the Python docs of today are too close to research articles and the 
specialized knowledge that implies.



This blog post is "in-the-face" [remainder of sentence moved below]
http://cryto.net/~joepie91/blog/2013/02/19/the-python-documentation-is-bad-and-you-should-feel-bad/


This blog post has several sins that you avoided, and did not help to 
improve the docs.  But anyway, to stay on topic...


> [moved] but has an example at the end of how docs might be rewritten.

The example is a separate page written after the original rant.
http://cryto.net/%7Ejoepie91/walk.html

This example expands 7 lines 6 times to about 42 and in the process 
manages to omit the following important info, which is about 1/5 of the 
original text.


"The visit function may modify names to influence the set of directories 
visited below dirname, e.g. to avoid visiting certain parts of the tree. 
(The object referred to by names must be modified in place, using del or 
slice assignment.)"


I am not sure where it would go in the template.  Templates can be 
straightjackets ;-).


The big issue is examples.  The problem with examples is that they are a 
maintenance burden.  Really.  Without testing, they are not dependable. 
And testing doc examples is not trivial.  So they need to really add value.


There are no examples in the os.path doc, and the particular issue for 
os.path is that results are idiosyncratic to a particular system. For 
some things, like the os.path functions, it is trivial for a user to try 
things out for themselves on their system.  The following took just a 
few minutes.


Python 3.6.1 (v3.6.1:69c0db5, Mar 21 2017, 18:41:36) [MSC v.1900 64 bit 
(AMD64)] on win32

Type "copyright", "credits" or "license()" for more information.
>>> import sys
>>> x = sys.executable
>>> import os.path as op
>>> op.isfile(x)
True
>>> op.isdir(x)
False
>>> x
'C:\\Programs\\Python36\\pythonw.exe'
>>> op.isabs(x)
True
>>> op.islink(x)
False
>>> op.getsize(x)
98968
>>> op.isdir(op.split(x)[0])
True
>>> op.splitdrive(x)
('C:', '\\Programs\\Python36\\pythonw.exe')
>>> op.join(x, 'Lib')
'C:\\Programs\\Python36\\pythonw.exe\\Lib'
>>> op.isdir(op.join(x, 'Lib'))
False
>>> op.getmtime(x)
1490136264.0

In any case, besides the tutorial and some of the reference chapters, 
python comes with some 'How-to's with examples.  There are also multiple 
3rd party sites that expand on the d

Re: Survey: improving the Python std lib docs

[Terry Reedy]

On 5/12/2017 6:02 AM, Steve D'Aprano wrote:


Here are a couple of suggestions for improving(?) the docs. What do you
think?
(They're not my ideas, the originated on Reddit.)



(1) Table of functions/classes at the start of each module doc


The only thing possibly 'new' here is 'each' versus 'selected'.  'Each' 
could be seen as an aspiration.  It could also be seen as a diversion 
from making concrete improvements, one chapter at a time, by a 
self-volunteer who will write and *commit to maintaining* such a table 
for a particular module.



The docs for builtins starts with a table of built-in functions:

https://docs.python.org/3/library/functions.html


Table has names only, alphabetically.  Maintenance will be collective.

https://docs.python.org/3/library/itertools.html#module-itertools

Categorized names, alphabetical within categories, with columns for 
arguments, results, and examples.  Raymond Hettinger maintains it.


> The statistics module shows something similar:
> https://docs.python.org/3/library/statistics.html

Categorized names with explanation, with a logical order within 
categories that is copied in the details section.  Steve will presumably 
make sure the index is updated if anyone adds new functions.


Steve, did you get any opposition to including that table?  Does the 
abstract idea of 'more tables' need discussion?



Docs for other modules should do similar, e.g. for the string module there
should be a table showing:

ascii_letters
ascii_lowercase
ascii_uppercase
capwords
digits
Formatter
hexdigits
octdigits
printable
punctuation
Template
whitespace



which link to the detailed documentation for that object.
https://docs.python.org/3/library/string.html


I disagree.  The alphabetical list mixes together 9 string constants, 
defining subsets of ascii characters, and 3 callables (1 function and 2 
classes).  The doc *could* start with a short table


Contents
| string constants | define subsets of ascii characters   |
| capwords | Capitalize each word in a string |
| Formatter| Custom formatting extending builtin format() |
| Template | Simple $-based string substitution   |

But this listing of mostly unused *objects* misses the 99% meat of the 
chapter, the definition format strings and format specs and the format() 
examples.  While this chapter originally documented the string module, 
it now mostly documents format() strings.  The doc for the string 
functions which are now strings methods was moved elsewhere.  (The 
capwords function is a vestigial remnant that was not made a string 
method.)  There is already a sidebar Table of Contents, which is 
generated automatically.


To me, the biggest deficiency of this chapter is the lack of any 
Formatter examples.  From a cursory reading, I have no idea how to use 
it.  I also question the placement of Formatter before the format() doc 
it depends on.


A table I would like is one that replaces the wordy contents of the 
'String constants' section, which should perhaps be renamed 'Character 
categories'.  I may have proposed this a decade ago and had the idea 
rejected.


| digits  | '0123456789'
...
| ascii_uppercase | 'ABCDEFGHIJKLMNOPQRSTUVWXYZ'
...
| printable   | digits + ascii_letters + punctuation + whitespace |

There should then be an explanation or reference to how at access 
similar unicode categories.

--

Conclusion: specific chapters need specific thought as to whether and 
what type of table might be useful.


--
Terry Jan Reedy

--
https://mail.python.org/mailman/listinfo/python-list

Re: Survey: improving the Python std lib docs

[jeanbigboute]

On Friday, May 12, 2017 at 3:02:58 AM UTC-7, Steve D'Aprano wrote:
> One of the more controversial aspects of the Python ecosystem is the Python
> docs. Some people love them, and some people hate them and describe them as
> horrible.
> 
> Here are a couple of suggestions for improving(?) the docs. What do you
> think?
>

.[ deletia ].

Thank you for bringing up this important topic.  As an occasional Python user, 
I find that Python documentation is all over the usability map - some great, 
some difficult.  The Python docs have been at best a starting point.  I usually 
need to go to other sites like this group, StackOverflow, and a blog or two to 
understand how to do something.  After I learn to do that one thing, I am not 
any more independent, self-reliant, or able to contribute back to the 
community.  Although Matlab gets a lot of grief in the open source community, 
its documentation is concise, complete, and self-contained.  

A table of functions/classes at the start of a Python doc would be very 
helpful.  I'd also like to see a tree-like overview of a package so I can get 
an idea of what's available and how deep the dot-indexed hierarchy goes.  I've 
tried to write code to extract/present this for myself and have failed.  IDEs 
and Notebooks allow descending a branch one dot at a time - very time 
consuming.  

Many of the docs go deep into CS terminology from the start which can be 
daunting. Here's the first paragraph from the 'Classes' documentation:
https://docs.python.org/2/tutorial/classes.html

"Compared with other programming languages, Python’s class mechanism adds 
classes with a minimum of new syntax and semantics. It is a mixture of the 
class mechanisms found in C++ and Modula-3. Python classes provide all the 
standard features of Object Oriented Programming: the class inheritance 
mechanism allows multiple base classes, a derived class can override any 
methods of its base class or classes, and a method can call the method of a 
base class with the same name."

I am sure it is all correct.  I just don't know what it means.  

I saw pkgutil referenced in answers to some StackOverflow questions and I 
looked into it:

https://docs.python.org/2/library/pkgutil.html

"This module provides utilities for the import system, in particular package 
support."

Then it gets very specialized.  

I am well aware of the distinction between documentation and tutorials. I think 
that the Python docs of today are too close to research articles and the 
specialized knowledge that implies.

This blog post is "in-the-face" but has an example at the end of how docs might 
be rewritten.

http://cryto.net/~joepie91/blog/2013/02/19/the-python-documentation-is-bad-and-you-should-feel-bad/

--- JBB
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Survey: improving the Python std lib docs

[dieter]

Steve D'Aprano  writes:
> One of the more controversial aspects of the Python ecosystem is the Python
> docs. Some people love them, and some people hate them and describe them as
> horrible.
>
> Here are a couple of suggestions for improving(?) the docs. What do you
> think?
>
> (They're not my ideas, the originated on Reddit.)
>
>
> (1) Table of functions/classes at the start of each module doc
>
> The docs for builtins starts with a table of built-in functions:
>
> https://docs.python.org/3/library/functions.html

>From my point of view, a good (manually maintained) documentation should not
contain information that can easily be obtained automatically.

Ideally, we should separate between overview information (explaining the
essential concepts and their relations) and detail information (list
of classes, functions, ...) with links between them. The detail information
is likely generated automatically from the source.

> ...
> (2) The PHP documentation allows you to search for a term by typing it into
> the URL after the domain, e.g. to search for "split", go to:
>
> http://php.net/split
>
>
> If you try the same thing with the Python docs:
>
> http://python.org/split
>
> you get a 404. Suggestion: 404s should redirect and search the docs.

Generate an "index" page from the complete documentation with links to
the term definitions. Then people who miss such a functionality can bookmark
that page.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Survey: improving the Python std lib docs

[Chris Angelico]

On Sat, May 13, 2017 at 4:05 AM,   wrote:
> On Friday, May 12, 2017 at 3:02:58 AM UTC-7, Steve D'Aprano wrote:
>
>> (1) Table of functions/classes at the start of each module doc
>>
>> The docs for builtins starts with a table of built-in functions:
>>
>> https://docs.python.org/3/library/functions.html
>>
>>
>> Docs for other modules should do similar...
>
> I agree with this suggestion.  I usually know what I want out of a module, 
> but I don't know the exact name(s) of the relevant function(s).  Frequently, 
> I find myself looking through the docs... and in parallel, I start a Python 
> interpreter, type "import foo", and then "dir(foo)" to see everything that 
> the module foo contains.
>

While I don't disagree with the docs suggestion, it's worth noting
that dir(foo) is a powerful feature, and part of what makes Python so
awesome. So don't be afraid to use it :)

TBH I'm +0.5 on the table; if it includes absolutely everything the
module offers, it'll be unworkably large on some modules, but if it
doesn't, how do you pick which are the "important" ones? Possibly this
is the right solution for most modules, but there'll be a few special
cases (eg argparse) that prefix it with "hey, check out this quick
start guide first".

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Survey: improving the Python std lib docs

[Ethan Furman]

On 05/12/2017 03:02 AM, Steve D'Aprano wrote:


Here are a couple of suggestions for improving(?) the docs. What do you
think?



(1) Table of functions/classes at the start of each module doc


I like this idea.  Even if I don't know the exact thing I am looking for I can 
usually get close from the names.

--
~Ethan~

--
https://mail.python.org/mailman/listinfo/python-list

Re: Survey: improving the Python std lib docs

[jladasky]

On Friday, May 12, 2017 at 3:02:58 AM UTC-7, Steve D'Aprano wrote:

> (1) Table of functions/classes at the start of each module doc
> 
> The docs for builtins starts with a table of built-in functions:
> 
> https://docs.python.org/3/library/functions.html
> 
> 
> Docs for other modules should do similar...

I agree with this suggestion.  I usually know what I want out of a module, but 
I don't know the exact name(s) of the relevant function(s).  Frequently, I find 
myself looking through the docs... and in parallel, I start a Python 
interpreter, type "import foo", and then "dir(foo)" to see everything that the 
module foo contains.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Survey: improving the Python std lib docs

[Dan Sommers]

On Fri, 12 May 2017 21:14:01 +1000, Chris Angelico wrote:

> On Fri, May 12, 2017 at 8:02 PM, Steve D'Aprano
>  wrote:
>> (2) The PHP documentation allows you to search for a term by typing it into
>> the URL after the domain, e.g. to search for "split", go to:
>>
>> http://php.net/split
>>
>>
>> If you try the same thing with the Python docs:
>>
>> http://python.org/split
>>
>> you get a 404. Suggestion: 404s should redirect and search the docs.
> 
> So long as we're talking about the existing search functionality, I'm
> a big NO on this one. It's way too slow to be used as a general 404.

I agree with ChrisA.  That said, if part of the 404 page were a link to
such a search, that may be convenient.

python.org/split does not exist.

Would you like to _search the python documentation for split_?

(where the underscore-bracketed text would be a link to
https://docs.python.org/3/search.html?q=split).

Dan
-- 
https://mail.python.org/mailman/listinfo/python-list