Re: [Python-Dev] Python 3 marketing document?

[Nick Coghlan]

I've tried to address the most common questions and misapprehensions in my
Python 3 Q & A:
http://python-notes.curiousefficiency.org/en/latest/python3/questions_and_answers.html

Cheers,
Nick.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python 3 marketing document?

[Brett Cannon]

On Thu, Jan 23, 2014 at 10:48 PM, Dan Stromberg  wrote:

> Has anyone published a web page or wiki page about what's great about
> Python 3.x?
>

In case you want a video I gave a presentation at PyCon US 2013 on Python
3.3 and tried to cover everything from 3.0 on.

http://www.youtube.com/watch?v=f_6vDi7ywuA
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Argument Clinic: what to do with builtins with non-standard signatures?

[Larry Hastings]

BACKGROUND  (skippable if you're a know-it-all)

Argument parsing for Python functions follows some very strict rules.
Unless the function implements its own parsing like so:

def black_box(*args, **kwargs):

there are some semantics that are always true.  For example:

* Any parameter that has a default value is optional, and vice-versa.

* It doesn't matter whether you pass in a parameter by name or by
  position, it behaves the same.

* You can see the default values by examining its inspect.Signature.

* Calling a function and passing in the default value for a parameter
  is identical to calling the function without that parameter.

  e.g. (assuming foo is a pure function):

 def foo(a=value): ...

 foo() == foo(value) == foo(a=value)

  With that signature, foo() literally can't tell the difference
  between those three calls.  And it doesn't matter what the type
  of value is or where you got it.


Python builtins are a little less regular.  They effectively do their own
parsing.  So they *could* do any crazy thing they want.  99.9% of the time
they do one of four standard things:
  * They parse their arguments with a single call to PyArg_ParseTuple().
  * They parse their arguments with a single call to
PyArg_ParseTupleAndKeywords().
  * They take a single argument of type "object" (METH_O).
  * They take no arguments (METH_NOARGS).

PyArg_ParseTupleAndKeywords() behaves almost exactly like a Python
function.  PyArg_ParseTuple() is a little less like a Python function,
because it doesn't support keyword arguments.  (Surely this behavior is
familiar to you!)

But then there's that funny 0.1%, the builtins that came up with their
own unique approach for parsing arguments--given them funny semantics.
Argument Clinic tries to accomodate these as best it can.   (That's why
it supports "optional groups" for example.)  But it can only do so much.


THE PROBLEM

Argument Clinic's original goal was to provide an introspection signature
for every builtin in Python.

But a small percentage of builtins have funny semantics that aren't
expressable in a valid Python signature.  This makes them hard to convert
to Argument Clinic, and makes their signature inaccurate.

If we want these functions to have an accurate Python introspection
signature, their argument parsing will have to change.


THE QUESTION

What should someone converting functions to Argument Clinic do
when faced with one of these functions?

Of course, the simplest answer is "nothing"--don't convert the
function to Argument Clinic.   We're in beta, and any change
that isn't a bugfix is impermissible.  We can try again for 3.5.

But if "any change" is impermissible, then we wouldn't have the
community support to convert to Argument Clinic right now.  The
community wants proper signatures for builtins badly enough that
we're doing it now, even though we're already in beta for Python
3.4.  Converting to Argument Clinic is, in the vast majority of
cases, a straightforward and low-risk change--but it is *a*
change.

Therefore perhaps the answer isn't an automatic "no".  Perhaps
additional straightforward, low-risk changes are permissible.  The
trick is, what constitutes a straightforward, low-risk change?
Where should we draw the line?  Let's discuss it.  Perhaps a
consensus will form around an answer besides a flat "no".


THE SPECIFICS

I'm sorting the problems we see into four rough categories.

a) Functions where there's a static Python value that behaves
   identically to not passing in that parameter (aka "the NULL problem")

   Example:
 _sha1.sha1().  Its optional parameter has a default value in C of 
NULL.
 We can't express NULL in a Python signature.  However, it just so 
happens

 that _sha1.sha1(b'') is exactly equivalent to _sha1.sha1(). b'' makes
 for a fine replacement default value.

 Same holds for list.__init__().  its optional "sequence" parameter has
 a default value in C of NULL.  But this signature:
list.__init__(sequence=())
 works fine.

 The way Clinic works, we can actually still use the NULL as the 
default

 value in C.  Clinic will let you use completely different values as
 the published default value in Python and the real default value in C.
 (Consenting adults rule and all that.)  So we could lie to Python and
 everything works just the way we want it to.

   Possible Solutions:
 0) Do nothing, don't convert the function.
 1) Use that clever static value as the default.


b) Functions where there's no static Python value that behaves 
identically to

   not passing in that parameter (aka "the dynamic default problem")

   There are functions with parameters whose defaults are mildly dynamic,
   responding to other parameters.

   Example:
 I forget its name, but someone recently showed me a builtin that took
 a list as its first parameter, and its optional second parameter
 defaul

Re: [Python-Dev] Argument Clinic: what to do with builtins with non-standard signatures?

[Larry Hastings]

On 01/24/2014 07:07 AM, Larry Hastings wrote:
b) Functions where there's no static Python value that behaves 
identically to

   not passing in that parameter (aka "the dynamic default problem")


Ouch!  Sorry, I forgot a detail here.  This can also be another form of 
NULL problem.  For example, socket.socket.getservbyport() takes an 
optional "protocol" argument.  Internally its default value is NULL.  
But there's really no good static string that we could use for the 
default.  Guido specifically suggested accepting None here to mean "use 
the internal default" should be fine.  But again this is a change, we're 
in beta, etc etc, discuss.



//arry/
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] lambda (x, y):

[Ram Rachum]

I don't like how in Python 3.x, you can't do this:

lambda (x, y): whatever

It's quite useful in Python 2

if I understand correctly, it's a side effect of such packed arguments not
being allowed in function definitions. (i.e. def instead of lambda)

Can you please refer me to the original discussion in which it was decided
to remove this grammar in Python 3? I'd like to understand the arguments
for it.


Thanks,
Ram.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] lambda (x, y):

[Brett Cannon]

On Fri, Jan 24, 2014 at 10:50 AM, Ram Rachum  wrote:

> I don't like how in Python 3.x, you can't do this:
>
> lambda (x, y): whatever
>
> It's quite useful in Python 2
>
> if I understand correctly, it's a side effect of such packed arguments not
> being allowed in function definitions. (i.e. def instead of lambda)
>
> Can you please refer me to the original discussion in which it was decided
> to remove this grammar in Python 3? I'd like to understand the arguments
> for it.
>

http://python.org/dev/peps/pep-3113/
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] lambda (x, y):

[Eric V. Smith]

On 1/24/2014 10:50 AM, Ram Rachum wrote:
> I don't like how in Python 3.x, you can't do this:
> 
> lambda (x, y): whatever
> 
> It's quite useful in Python 2
> 
> if I understand correctly, it's a side effect of such packed arguments
> not being allowed in function definitions. (i.e. def instead of lambda)

You can still do:
>>> fn = lambda x, y: x+y
>>> fn(20, 22)
42

It's just tuple unpacking which doesn't work.

> Can you please refer me to the original discussion in which it was
> decided to remove this grammar in Python 3? I'd like to understand the
> arguments for it. 

See PEP 3113.

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python 3 marketing document?

[Wes Turner]

Hardly marketing documents, but potentially useful nonetheless:

http://docs.python.org/3.4/whatsnew/index.html

https://bitbucket.org/gutworth/six/src/tip/six.py

https://github.com/nandoflorestan/nine/blob/master/nine/__init__.py

http://docs.python.org/3/library/2to3.html

https://pypi.python.org/pypi/
backports.ssl_match_hostname

http:// 
docs.python.org
/3.4/library/ 
asyncio.html

The new pathlib is pretty cool:

http://docs.python.org/3.4/whatsnew/3.4.html#new-modules

http://docs.python.org/3.4/library/pathlib.html#module-pathlib

Wes Turner
On Jan 23, 2014 9:49 PM, "Dan Stromberg"  wrote:

> Has anyone published a web page or wiki page about what's great about
> Python 3.x?
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/wes.turner%40gmail.com
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Enable Hostname and Certificate Chain Validation

[Cory Benfield]

On 24 January 2014 03:06, Stephen J. Turnbull  wrote:
> Are you kidding?  These *aren't* the apps that I care about breaking,
> and I know that the PHBs won't pay attention to what I say about
> fixing their sites and cert chains (believe me, I've tried, and the
> answer is as Paul Moore says: the users can punch the "go ahead anyway
> button," what's the big deal here?), they'll just deprecate Python.

Surely the solution here isn't to say "well then, let's be insecure by
default", it's to provide a "go ahead anyway" button. That at least lets us
push the choice to be insecure by default onto someone else. The idea that
an enterprise will deprecate Python instead of adding a single environment
variable or one line at the top of their scripts seems hugely unlikely.

As an example, Requests provides a "stop verifying certs" button, and
that works fine for us. (I know that Requests is outside the stdlib and so
it's not a perfect analogy, but it's serviceable.) I suspect most people who
want this change don't care if users have an easy way to circumvent it,
we just want to have the user/enterprise make that choice for themselves.
Put another way, we want the average user to fall into a pit of success.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Enable Hostname and Certificate Chain Validation

[Cory Benfield]

On 23 January 2014 08:37, Stephen J. Turnbull  wrote:
>
> I don't know what the right answer is, but this needs careful
> discussion and amelioration, not just "you're broken, so take the
> consequences!"
>
Absolutely. =)

With that said, having a great big button to turn the change off
(e.g. environment variable, global setting) feels like an acceptable
mitigation to me, but then I'm probably still more aggressive than the
core developers! Either way, it looks like the deprecation dance is
going to be the consensus decision here.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Argument Clinic: what to do with builtins with non-standard signatures?

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/24/2014 10:07 AM, Larry Hastings wrote:
> THE SPECIFICS
> 
> I'm sorting the problems we see into four rough categories.
> 
> a) Functions where there's a static Python value that behaves 
> identically to not passing in that parameter (aka "the NULL problem")
> 
> Example: _sha1.sha1().  Its optional parameter has a default value in
> C of NULL. We can't express NULL in a Python signature.  However, it
> just so happens that _sha1.sha1(b'') is exactly equivalent to
> _sha1.sha1(). b'' makes for a fine replacement default value.
> 
> Same holds for list.__init__().  its optional "sequence" parameter
> has a default value in C of NULL.  But this signature: 
> list.__init__(sequence=()) works fine.
> 
> The way Clinic works, we can actually still use the NULL as the 
> default value in C.  Clinic will let you use completely different
> values as the published default value in Python and the real default
> value in C. (Consenting adults rule and all that.)  So we could lie to
> Python and everything works just the way we want it to.
> 
> Possible Solutions: 0) Do nothing, don't convert the function. 1) Use
> that clever static value as the default.

I prefer #1.

> b) Functions where there's no static Python value that behaves 
> identically to not passing in that parameter (aka "the dynamic default
> problem")
> 
> There are functions with parameters whose defaults are mildly
> dynamic, responding to other parameters.
> 
> Example: I forget its name, but someone recently showed me a builtin
> that took a list as its first parameter, and its optional second
> parameter defaulted to the length of the list.  As I recall this
> function didn't allow negative numbers, so -1 wasn't a good fit.
> 
> Possible solutions: 0) Do nothing, don't convert the function. 1) Use
> a magic value as None.  Preferably of the same type as the function
> accepts, but failing that use None.  If they pass in the magic value
> use the previous default value.  Guido himself suggested this in 2)
> Use an Argument Clinic "optional group".  This only works for 
> functions that don't support keyword arguments.  Also, I hate this,
> because "optional groups" are not expressable in Python syntax, so
> these functions automatically have invalid signatures.

I prefer #1.

> c) Functions that accept an 'int' when they mean 'boolean' (aka the 
> "ints instead of bools" problem)
> 
> This is specific but surprisingly common.
> 
> Before Python 3.3 there was no PyArg_ParseTuple format unit that
> meant "boolean value".  Functions generally used "i" (int).  Even
> older functions accepted an object and called PyLong_AsLong() on it. 
> Passing in True or False for "i" (or PyLong_AsLong()) works, because 
> boolean inherits from long.   But anything other than ints and bools 
> throws an exception.
> 
> In Python 3.3 I added the "p" format unit for boolean arguments. This
> calls PyObject_IsTrue() which accepts nearly any Python value.
> 
> I assert that Python has a crystal clear definition of what 
> constitutes "true" and "false".  These parameters are clearly intended
> as booleans but they don't conform to the boolean protocol.  So I
> suggest every instance of this is a (very mild!) bug.  But changing
> these parameters to use "p" is a change: they'll accept many more
> values than before.
> 
> Right now people convert these using 'int' because that's an exact 
> match.  But sometimes they are optional, and the person doing the 
> conversion wants to use True or False as a default value, and it 
> doesn't work: Argument Clinic's type enforcement complains and they
> have to work around it.  (Argument Clinic has to enforce some 
> type-safety here because the values are used as defaults for C 
> variables.)  I've been asked to allow True and False as defaults for
> "int" parameters specifically because of this.
> 
> Example: str.splitlines(keepends)
> 
> Solution: 1) Use "bool". 2) Use "int", and I'll go relax Argument
> Clinic so they can use bool values as defaults for int parameters.

I prefer #1.

> d) Functions with behavior that deliberately defy being expressed as
> a Python signature (aka the "untranslatable signature" problem)
> 
> Example: itertools.repeat(), which behaves differently depending on
> whether "times" is supplied as a positional or keyword argument.  (If 
> "times" is <0, and was supplied via position, the function yields 0
> times. If "times" is <0, and was supplied via keyword, the function
> yields infinitely-many times.)
> 
> Solution: 0) Do nothing, don't convert the function. 1) Change the
> signature until it is Python compatible.  This new signature *must*
> accept a superset of the arguments accepted by the existing signature.
> (This is being discussed right now in issue #19145.)

I can't imagine justifying such an API design in the first place, but
sometimes things "jest grew", rather than being designed.  I'm in favor
of # 1, in any case.  If real backward

Re: [Python-Dev] Argument Clinic: what to do with builtins with non-standard signatures?

[Serhiy Storchaka]

24.01.14 17:07, Larry Hastings написав(ла):

a) Functions where there's a static Python value that behaves
identically to not passing in that parameter (aka "the NULL problem")

[...]

Possible Solutions:
  0) Do nothing, don't convert the function.
  1) Use that clever static value as the default.


I think #1 is reasonable solution. Internals of C function are just 
implementation details.




b) Functions where there's no static Python value that behaves
identically to
not passing in that parameter (aka "the dynamic default problem")

There are functions with parameters whose defaults are mildly dynamic,
responding to other parameters.

Example:
  I forget its name, but someone recently showed me a builtin that took
  a list as its first parameter, and its optional second parameter
  defaulted to the length of the list.  As I recall this function didn't
  allow negative numbers, so -1 wasn't a good fit.

Possible solutions:
  0) Do nothing, don't convert the function.
  1) Use a magic value as None.  Preferably of the same type as the
 function accepts, but failing that use None.  If they pass in
 the magic value use the previous default value.  Guido himself
 suggested this in
  2) Use an Argument Clinic "optional group".  This only works for
 functions that don't support keyword arguments.  Also, I hate
 this, because "optional groups" are not expressable in Python
 syntax, so these functions automatically have invalid signatures.


This is list.index(self, item, start=0, stop=len(self). Vajrasky Kok 
works on this in issue20185 [1].


In this particular case we can use default stop=sys.maxsize, as in many 
other places.




c) Functions that accept an 'int' when they mean 'boolean' (aka the
"ints instead of bools" problem)

[...]

I assert that Python has a crystal clear definition of what
constitutes "true" and "false".  These parameters are clearly
intended as booleans but they don't conform to the boolean
protocol.  So I suggest every instance of this is a (very mild!)
bug.  But changing these parameters to use "p" is a change: they'll
accept many more values than before.


See issue15999 [2] which 16 months waits for review.


Solution:
  1) Use "bool".
  2) Use "int", and I'll go relax Argument Clinic so they
 can use bool values as defaults for int parameters.


I use

int(c_default="0") = False
int(c_default="1") = True

See also rejected issue20282 [3].



d) Functions with behavior that deliberately defy being expressed as a
Python signature (aka the "untranslatable signature" problem)

Example:
  itertools.repeat(), which behaves differently depending on whether
  "times" is supplied as a positional or keyword argument.  (If
  "times" is <0, and was supplied via position, the function yields
  0 times. If "times" is <0, and was supplied via keyword, the
  function yields infinitely-many times.)

Solution:
  0) Do nothing, don't convert the function.
  1) Change the signature until it is Python compatible.  This new
 signature *must* accept a superset of the arguments accepted
 by the existing signature.  (This is being discussed right
 now in issue #19145.)


In this particular case this is a bug and should be fixed irrespective 
of Argument Clinic.


If we implemented this function in pure Python, we would have used the 
sentinel idiom.


_forever = object()

def repeat(value, times=_forever):
if times is _forever:
...
else:
...

We need an equivalent to the sentinel idiom in Argument Clinic.


There is fifth category. The default value is C constant which is not 
exposed to Python. For example in the zlib module:


zlib.decompress(data, [wbits, [bufsize]])


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] str.rreplace

[Ram Rachum]

Question: Why is there no str.rreplace in Python?
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] str.rreplace

[Chris Angelico]

On Sat, Jan 25, 2014 at 3:38 AM, Antoine Pitrou  wrote:
> On Fri, 24 Jan 2014 18:32:17 +0200
> Ram Rachum  wrote:
>> Question: Why is there no str.rreplace in Python?
>
> What would it do?
> (also, I think such questions are better asked on python-ideas)

Or python-list. Chances are there's a way to do it already, which
would be of interest to other people who might be looking. But I've no
idea what semantics are expected. :)

ChrisA
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Argument Clinic: what to do with builtins with non-standard signatures?

[Serhiy Storchaka]

24.01.14 18:28, Serhiy Storchaka написав(ла):

24.01.14 17:07, Larry Hastings написав(ла):

a) Functions where there's a static Python value that behaves
identically to not passing in that parameter (aka "the NULL problem")

[...]

Possible Solutions:
  0) Do nothing, don't convert the function.
  1) Use that clever static value as the default.


I think #1 is reasonable solution. Internals of C function are just
implementation details.



b) Functions where there's no static Python value that behaves
identically to
not passing in that parameter (aka "the dynamic default problem")

There are functions with parameters whose defaults are mildly
dynamic,
responding to other parameters.

Example:
  I forget its name, but someone recently showed me a builtin that
took
  a list as its first parameter, and its optional second parameter
  defaulted to the length of the list.  As I recall this function
didn't
  allow negative numbers, so -1 wasn't a good fit.

Possible solutions:
  0) Do nothing, don't convert the function.
  1) Use a magic value as None.  Preferably of the same type as the
 function accepts, but failing that use None.  If they pass in
 the magic value use the previous default value.  Guido himself
 suggested this in
  2) Use an Argument Clinic "optional group".  This only works for
 functions that don't support keyword arguments.  Also, I hate
 this, because "optional groups" are not expressable in Python
 syntax, so these functions automatically have invalid
signatures.


This is list.index(self, item, start=0, stop=len(self). Vajrasky Kok
works on this in issue20185 [1].

In this particular case we can use default stop=sys.maxsize, as in many
other places.



c) Functions that accept an 'int' when they mean 'boolean' (aka the
"ints instead of bools" problem)

[...]

I assert that Python has a crystal clear definition of what
constitutes "true" and "false".  These parameters are clearly
intended as booleans but they don't conform to the boolean
protocol.  So I suggest every instance of this is a (very mild!)
bug.  But changing these parameters to use "p" is a change: they'll
accept many more values than before.


See issue15999 [2] which 16 months waits for review.


Solution:
  1) Use "bool".
  2) Use "int", and I'll go relax Argument Clinic so they
 can use bool values as defaults for int parameters.


I use

 int(c_default="0") = False
 int(c_default="1") = True

See also rejected issue20282 [3].



d) Functions with behavior that deliberately defy being expressed as a
Python signature (aka the "untranslatable signature" problem)

Example:
  itertools.repeat(), which behaves differently depending on whether
  "times" is supplied as a positional or keyword argument.  (If
  "times" is <0, and was supplied via position, the function yields
  0 times. If "times" is <0, and was supplied via keyword, the
  function yields infinitely-many times.)

Solution:
  0) Do nothing, don't convert the function.
  1) Change the signature until it is Python compatible.  This new
 signature *must* accept a superset of the arguments accepted
 by the existing signature.  (This is being discussed right
 now in issue #19145.)


In this particular case this is a bug and should be fixed irrespective
of Argument Clinic.

If we implemented this function in pure Python, we would have used the
sentinel idiom.

_forever = object()

def repeat(value, times=_forever):
 if times is _forever:
 ...
 else:
 ...

We need an equivalent to the sentinel idiom in Argument Clinic.


There is fifth category. The default value is C constant which is not
exposed to Python. For example in the zlib module:

zlib.decompress(data, [wbits, [bufsize]])


Oh, I have deleted links.

[1] http://bugs.python.org/issue20185
[2] http://bugs.python.org/issue15999
[3] http://bugs.python.org/issue20282


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python 3 marketing document?

[Jesse Noller]

fwiw, I'm offering the keys/account/etc for getpython3.com to whomever
has the time to keep it fresh and up to date.

On Fri, Jan 24, 2014 at 8:36 AM, Wes Turner  wrote:
> Hardly marketing documents, but potentially useful nonetheless:
>
> http://docs.python.org/3.4/whatsnew/index.html
>
> https://bitbucket.org/gutworth/six/src/tip/six.py
>
> https://github.com/nandoflorestan/nine/blob/master/nine/__init__.py
>
> http://docs.python.org/3/library/2to3.html
>
> https://pypi.python.org/pypi/backports.ssl_match_hostname
>
> http://docs.python.org/3.4/library/asyncio.html
>
> The new pathlib is pretty cool:
>
> http://docs.python.org/3.4/whatsnew/3.4.html#new-modules
>
> http://docs.python.org/3.4/library/pathlib.html#module-pathlib
>
> Wes Turner
>
> On Jan 23, 2014 9:49 PM, "Dan Stromberg"  wrote:
>>
>> Has anyone published a web page or wiki page about what's great about
>> Python 3.x?
>> ___
>> Python-Dev mailing list
>> Python-Dev@python.org
>> https://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe:
>> https://mail.python.org/mailman/options/python-dev/wes.turner%40gmail.com
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/jnoller%40gmail.com
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] str.rreplace

[Antoine Pitrou]

On Fri, 24 Jan 2014 18:32:17 +0200
Ram Rachum  wrote:
> Question: Why is there no str.rreplace in Python?

What would it do?
(also, I think such questions are better asked on python-ideas)

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] str.rreplace

[Ram Rachum]

You see, Antoine, *you* know that it's better asked on python-ideas because
you know it doesn't exist in Python, therefore it's an idea for an
addition. However, when a person like me asks this question, he does not
know whether it exists or not, so he can't know whether he's proposing a
new idea or whether it's something that exists under a different name or
whether that's something that can't exist because of some unknown reason
that the asker didn't think of.

Now that I know it doesn't exist, I'll ask this on python-ideas.


Thanks,
Ram.


On Fri, Jan 24, 2014 at 6:38 PM, Antoine Pitrou  wrote:

> On Fri, 24 Jan 2014 18:32:17 +0200
> Ram Rachum  wrote:
> > Question: Why is there no str.rreplace in Python?
>
> What would it do?
> (also, I think such questions are better asked on python-ideas)
>
> Regards
>
> Antoine.
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/ram%40rachum.com
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] str.rreplace

[Mark Lawrence]

On 24/01/2014 16:32, Ram Rachum wrote:

Question: Why is there no str.rreplace in Python?



It's not needed.  Is this *REALLY* relevant to this list?

--
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.


Mark Lawrence

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] str.rreplace

[Ryan Gonzalez]

http://stackoverflow.com/questions/2556108/how-to-replace-the-last-occurence-of-an-expression-in-a-string



On Fri, Jan 24, 2014 at 10:32 AM, Ram Rachum  wrote:

> Question: Why is there no str.rreplace in Python?
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com
>
>


-- 
Ryan
If anybody ever asks me why I prefer C++ to C, my answer will be simple:
"It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was
nul-terminated."
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python 3 marketing document?

[Wes Turner]

Wes Turner
On Jan 24, 2014 10:37 AM, "Jesse Noller"  wrote:
>
> fwiw, I'm offering the keys/account/etc for getpython3.com to whomever
> has the time to keep it fresh and up to date.

It shouldn't be too difficult to add a GET JSON view to python3wos:

https://python3wos.appspot.com

>
> On Fri, Jan 24, 2014 at 8:36 AM, Wes Turner  wrote:
> > Hardly marketing documents, but potentially useful nonetheless:
> >
> > http://docs.python.org/3.4/whatsnew/index.html
> >
> > https://bitbucket.org/gutworth/six/src/tip/six.py
> >
> > https://github.com/nandoflorestan/nine/blob/master/nine/__init__.py
> >
> > http://docs.python.org/3/library/2to3.html
> >
> > https://pypi.python.org/pypi/backports.ssl_match_hostname
> >
> > http://docs.python.org/3.4/library/asyncio.html
> >
> > The new pathlib is pretty cool:
> >
> > http://docs.python.org/3.4/whatsnew/3.4.html#new-modules
> >
> > http://docs.python.org/3.4/library/pathlib.html#module-pathlib
> >
> > Wes Turner
> >
> > On Jan 23, 2014 9:49 PM, "Dan Stromberg"  wrote:
> >>
> >> Has anyone published a web page or wiki page about what's great about
> >> Python 3.x?
> >> ___
> >> Python-Dev mailing list
> >> Python-Dev@python.org
> >> https://mail.python.org/mailman/listinfo/python-dev
> >> Unsubscribe:
> >>
https://mail.python.org/mailman/options/python-dev/wes.turner%40gmail.com
> >
> >
> > ___
> > Python-Dev mailing list
> > Python-Dev@python.org
> > https://mail.python.org/mailman/listinfo/python-dev
> > Unsubscribe:
> > https://mail.python.org/mailman/options/python-dev/jnoller%40gmail.com
> >
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] str.rreplace

[Terry Reedy]

On 1/24/2014 11:32 AM, Ram Rachum wrote:

Question: Why is there no str.rreplace in Python?


Ram, this list is for discussing the development of the next few 
releases of CPython. General questions should go to python-list.


--
Terry Jan Reedy

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Summary of Python tracker Issues

[Python tracker]

ACTIVITY SUMMARY (2014-01-17 - 2014-01-24)
Python tracker at http://bugs.python.org/

To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.

Issues counts and deltas:
  open4475 (+38)
  closed 27678 (+54)
  total  32153 (+92)

Open issues with patches: 2039 


Issues opened (70)
==

#17390: display python version on idle title bar
http://bugs.python.org/issue17390  reopened by ezio.melotti

#18147: SSL: diagnostic functions to list loaded CA certs
http://bugs.python.org/issue18147  reopened by r.david.murray

#19081: zipimport behaves badly when the zip file changes while the pr
http://bugs.python.org/issue19081  reopened by gregory.p.smith

#20290: inspect module bug for modules with same filename
http://bugs.python.org/issue20290  opened by cqxz

#20291: Argument Clinic should understand *args and **kwargs parameter
http://bugs.python.org/issue20291  opened by larry

#20293: pydoc fails with the "unspecified" default value
http://bugs.python.org/issue20293  opened by serhiy.storchaka

#20295: imghdr add openexr support
http://bugs.python.org/issue20295  opened by mvignali

#20296: PyArg_ParseTuple 2.X docs mention int for "t#", but "Py_ssize_
http://bugs.python.org/issue20296  opened by rlb

#20297: concurrent.futures.as_completed() installs waiters for already
http://bugs.python.org/issue20297  opened by glangford

#20303: Argument Clinic: optional groups
http://bugs.python.org/issue20303  opened by serhiy.storchaka

#20304: Argument Clinic: char convertor should use default values of t
http://bugs.python.org/issue20304  opened by taleinat

#20305: Android's incomplete locale.h implementation prevents cross-co
http://bugs.python.org/issue20305  opened by shiz

#20306: Lack of pw_gecos field in Android's struct passwd causes cross
http://bugs.python.org/issue20306  opened by shiz

#20307: Android's failure to expose SYS_* system call constants causes
http://bugs.python.org/issue20307  opened by shiz

#20308: inspect.Signature doesn't support user classes without __init_
http://bugs.python.org/issue20308  opened by larry

#20309: Not all method descriptors are callable
http://bugs.python.org/issue20309  opened by larry

#20311: epoll.poll(timeout) and PollSelector.select(timeout) must roun
http://bugs.python.org/issue20311  opened by haypo

#20314: Potentially confusing formulation in 6.1.4. Templatestrings
http://bugs.python.org/issue20314  opened by Gerrit.Holl

#20317: ExitStack hang if enough nested exceptions
http://bugs.python.org/issue20317  opened by jcflack

#20318: subprocess.Popen can hang in threaded applications
http://bugs.python.org/issue20318  opened by Andrew.Lutomirski

#20319: concurrent.futures.wait() can block forever even if Futures ha
http://bugs.python.org/issue20319  opened by glangford

#20320: select.select(timeout) and select.kqueue.control(timeout) must
http://bugs.python.org/issue20320  opened by haypo

#20322: Upgrade ensurepip's pip and setuptools
http://bugs.python.org/issue20322  opened by dstufft

#20323: Argument Clinic: docstring_prototype output causes build failu
http://bugs.python.org/issue20323  opened by zach.ware

#20325: Argument Clinic: self converters are not preserved when clonin
http://bugs.python.org/issue20325  opened by taleinat

#20326: Argument Clinic should use a non-error-prone syntax to mark te
http://bugs.python.org/issue20326  opened by larry

#20328: mailbox:
http://bugs.python.org/issue20328  opened by jmtd

#20329: zipfile.extractall fails in Posix shell with utf-8 filename
http://bugs.python.org/issue20329  opened by Laurent.Mazuel

#20330: PEP 342 is outdated
http://bugs.python.org/issue20330  opened by msmhrt

#20331: Fix various fd leaks
http://bugs.python.org/issue20331  opened by serhiy.storchaka

#20333: argparse subparser usage message hides main parser usage
http://bugs.python.org/issue20333  opened by Martin.d'Anjou

#20334: make inspect Signature hashable
http://bugs.python.org/issue20334  opened by yselivanov

#20335: bytes constructor accepts more than one argument even if the f
http://bugs.python.org/issue20335  opened by rndblnch

#20336: test_asyncio: relax timings even more
http://bugs.python.org/issue20336  opened by skrah

#20337: bdist_rpm should support %config(noreplace)
http://bugs.python.org/issue20337  opened by kv

#20338: Idle: increase max calltip width
http://bugs.python.org/issue20338  opened by terry.reedy

#20339: Make bytes() use tp_as_buffer for cmp
http://bugs.python.org/issue20339  opened by nascheme

#20341: Argument Clinic: add "nullable ints"
http://bugs.python.org/issue20341  opened by larry

#20342: Endianness not detected correctly due to AC_RUN_IFELSE macros
http://bugs.python.org/issue20342  opened by zaytsev

#20344: subprocess.check_output() docs misrepresent what shell=True do
http://bugs.python.org/issue20344  opened by klausman

#20345: Better logging defaults
http://bugs.python.org/issue20345  opened by ArneBab

#20346: 

Re: [Python-Dev] str.rreplace

[Ram Rachum]

Hmm, on one hand I understand the need for the separation between
python-dev and python-list, but on the other hand I don't think python-list
is a good place to discuss Python, the language.

I now looked at the 17 most recent python-list threads. Out of them:

 - 58% are about third-party packages.
 - 17% are off-topic (not even programming related)
 - 11% are 2-vs-3 discussions
 - 5% are job offers.
 - 5% (which is just one thread out of 17) is about Python the language.

So can you understand why someone would be reluctant to start a discussion
in python-list about Python the language there? Especially if this is the
same place where beginners might ask newbies questions about Python? (So
not only are actual Python questions just 5% of the content, non-newbie
questions are just a subset of that 5%.)



it's full of people asking about third-party Python packages, or asking
newbie questions.


On Fri, Jan 24, 2014 at 7:04 PM, Terry Reedy  wrote:

> On 1/24/2014 11:32 AM, Ram Rachum wrote:
>
>> Question: Why is there no str.rreplace in Python?
>>
>
> Ram, this list is for discussing the development of the next few releases
> of CPython. General questions should go to python-list.
>
> --
> Terry Jan Reedy
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> ram%40rachum.com
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] str.rreplace

[Brett Cannon]

On Fri, Jan 24, 2014 at 11:46 AM, Ram Rachum  wrote:

> You see, Antoine, *you* know that it's better asked on python-ideas
> because you know it doesn't exist in Python, therefore it's an idea for an
> addition. However, when a person like me asks this question, he does not
> know whether it exists or not, so he can't know whether he's proposing a
> new idea or whether it's something that exists under a different name or
> whether that's something that can't exist because of some unknown reason
> that the asker didn't think of.
>
> Now that I know it doesn't exist, I'll ask this on python-ideas.
>

I think there might be a language issue here because you originally said "Why
is there no str.rreplace in Python?" which shows you already knew it didn't
exist. Did you mean to say you wanted to know *why* it didn't exist?

Even in that case, if searching for [python str.rreplace] didn't turn up
anything then chances are there was no proposal, which makes it a new idea
and thus belongs on python-ideas. Basically the rule of thumb is anything
considered new goes to python-ideas first.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] str.rreplace

[Ram Rachum]

I knew it didn't exist by that name, but couldn't know whether there was
another function that did the same thing or technique to make it not needed.

So I couldn't know whether it's new or not, therefore I couldn't know
whether it should be on python-ideas or not.


On Fri, Jan 24, 2014 at 7:31 PM, Brett Cannon  wrote:

>
>
>
> On Fri, Jan 24, 2014 at 11:46 AM, Ram Rachum  wrote:
>
>> You see, Antoine, *you* know that it's better asked on python-ideas
>> because you know it doesn't exist in Python, therefore it's an idea for an
>> addition. However, when a person like me asks this question, he does not
>> know whether it exists or not, so he can't know whether he's proposing a
>> new idea or whether it's something that exists under a different name or
>> whether that's something that can't exist because of some unknown reason
>> that the asker didn't think of.
>>
>> Now that I know it doesn't exist, I'll ask this on python-ideas.
>>
>
> I think there might be a language issue here because you originally said "Why
> is there no str.rreplace in Python?" which shows you already knew it didn't
> exist. Did you mean to say you wanted to know *why* it didn't exist?
>
> Even in that case, if searching for [python str.rreplace] didn't turn up
> anything then chances are there was no proposal, which makes it a new idea
> and thus belongs on python-ideas. Basically the rule of thumb is anything
> considered new goes to python-ideas first.
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] str.rreplace

[Mark Lawrence]

On 24/01/2014 17:19, Ram Rachum wrote:

Hmm, on one hand I understand the need for the separation between
python-dev and python-list, but on the other hand I don't think
python-list is a good place to discuss Python, the language.

I now looked at the 17 most recent python-list threads. Out of them:

  - 58% are about third-party packages.
  - 17% are off-topic (not even programming related)
  - 11% are 2-vs-3 discussions
  - 5% are job offers.
  - 5% (which is just one thread out of 17) is about Python the language.




I'm extremely impressed by your knowledge of statistics, it must have 
taken you many man years of effort to analyse all 17 threads in such detail.



So can you understand why someone would be reluctant to start a
discussion in python-list about Python the language there? Especially if
this is the same place where beginners might ask newbies questions about
Python? (So not only are actual Python questions just 5% of the content,
non-newbie questions are just a subset of that 5%.)

it's full of people asking about third-party Python packages, or asking
newbie questions.



How terrible, fancy having the audacity to ask about third party 
packages or newbie questions on the *MAIN* Python mailing list.  There's 
yet another reason to bring back the death penalty in the UK.


--
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.


Mark Lawrence

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] str.rreplace

[Brett Cannon]

On Fri, Jan 24, 2014 at 12:33 PM, Ram Rachum  wrote:

> I knew it didn't exist by that name, but couldn't know whether there was
> another function that did the same thing or technique to make it not needed.
>
> So I couldn't know whether it's new or not, therefore I couldn't know
> whether it should be on python-ideas or not.
>

So then you were simply wondering about its existence, for which you should
go to python-list or python-ideas first. Python-ideas exists *explicitly*
as a filter for this kind of question which is why people are saying it
should have gone there first (or to python-list).

If you have any doubt as to whether a question should go here or not, then
err on the side of caution and post to python-ideas or python-list first.

-Brett


>
>
>
> On Fri, Jan 24, 2014 at 7:31 PM, Brett Cannon  wrote:
>
>>
>>
>>
>> On Fri, Jan 24, 2014 at 11:46 AM, Ram Rachum  wrote:
>>
>>> You see, Antoine, *you* know that it's better asked on python-ideas
>>> because you know it doesn't exist in Python, therefore it's an idea for an
>>> addition. However, when a person like me asks this question, he does not
>>> know whether it exists or not, so he can't know whether he's proposing a
>>> new idea or whether it's something that exists under a different name or
>>> whether that's something that can't exist because of some unknown reason
>>> that the asker didn't think of.
>>>
>>> Now that I know it doesn't exist, I'll ask this on python-ideas.
>>>
>>
>> I think there might be a language issue here because you originally said "Why
>> is there no str.rreplace in Python?" which shows you already knew it didn't
>> exist. Did you mean to say you wanted to know *why* it didn't exist?
>>
>> Even in that case, if searching for [python str.rreplace] didn't turn up
>> anything then chances are there was no proposal, which makes it a new idea
>> and thus belongs on python-ideas. Basically the rule of thumb is anything
>> considered new goes to python-ideas first.
>>
>
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] str.rreplace

[Terry Reedy]

On 1/24/2014 12:19 PM, Ram Rachum wrote:

Hmm, on one hand I understand the need for the separation between
python-dev and python-list, but on the other hand I don't think
python-list is a good place to discuss Python, the language.


Python-list is the place for such discussions. Questions such as yours 
are common. I have been reading it for almost 17 years.


--
Terry Jan Reedy

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] str.rreplace

[Chris Angelico]

On Sat, Jan 25, 2014 at 4:19 AM, Ram Rachum  wrote:
> I now looked at the 17 most recent python-list threads. Out of them:
>
>  - 58% are about third-party packages.
>  - 17% are off-topic (not even programming related)
>  - 11% are 2-vs-3 discussions
>  - 5% are job offers.
>  - 5% (which is just one thread out of 17) is about Python the language.

My analysis here is based on what I see arriving in Gmail, so some of
them may have been dropped into spam. But these are the threads with
the most recent posts:

"The potential for a Python 2.8" - discussing the language, though the
last few posts drifted off into numeric jokes (also fun).
"Class and instance related questions" - short thread but completely
on topic (so far)
"Python declarative" - not all the code shown has been Python, and a
lot of the discussion centers around alternatives like XML and JSON,
but it's definitely focused on Python
"datetime as subclass of date" - on topic
"Can post a code but afraid of plagiarism" - haven't been following
it, but last I saw it was on topic
"Elementree and insert new element if it is not present" - might count
as discussion of a separate module, I guess
"generate De Bruijn sequence memory and string vs lists" - all about
how to do it in Python, looks on topic to me
"Need Help with Programming Science Project" - the OP never said that
the program was to be in Python, but if we assume that, it's
completely on topic

Further down than that we have a few about SQLite, which Python comes
with, and an announcement of a new version of Dipy. Far as I can see,
that's only two threads that are truly about third-party modules (that
and lxml). Yes, there's some noise on the list, but it's not as bad as
16/17ths of the threads.

Maybe you're reading it in some way other than the mailing list, and
it accrues more noise?

ChrisA
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] str.rreplace

[Ram Rachum]

Okay, next time I'll ask on python-ideas. (I do hope that no one there will
be angry that I'm posting a question there rather than an idea...)


On Fri, Jan 24, 2014 at 7:41 PM, Brett Cannon  wrote:

>
>
>
> On Fri, Jan 24, 2014 at 12:33 PM, Ram Rachum  wrote:
>
>> I knew it didn't exist by that name, but couldn't know whether there was
>> another function that did the same thing or technique to make it not needed.
>>
>> So I couldn't know whether it's new or not, therefore I couldn't know
>> whether it should be on python-ideas or not.
>>
>
> So then you were simply wondering about its existence, for which you
> should go to python-list or python-ideas first. Python-ideas exists
> *explicitly* as a filter for this kind of question which is why people are
> saying it should have gone there first (or to python-list).
>
> If you have any doubt as to whether a question should go here or not, then
> err on the side of caution and post to python-ideas or python-list first.
>
> -Brett
>
>
>>
>>
>>
>> On Fri, Jan 24, 2014 at 7:31 PM, Brett Cannon  wrote:
>>
>>>
>>>
>>>
>>> On Fri, Jan 24, 2014 at 11:46 AM, Ram Rachum  wrote:
>>>
 You see, Antoine, *you* know that it's better asked on python-ideas
 because you know it doesn't exist in Python, therefore it's an idea for an
 addition. However, when a person like me asks this question, he does not
 know whether it exists or not, so he can't know whether he's proposing a
 new idea or whether it's something that exists under a different name or
 whether that's something that can't exist because of some unknown reason
 that the asker didn't think of.

 Now that I know it doesn't exist, I'll ask this on python-ideas.

>>>
>>> I think there might be a language issue here because you originally said
>>> "Why is there no str.rreplace in Python?" which shows you already knew
>>> it didn't exist. Did you mean to say you wanted to know *why* it didn't
>>> exist?
>>>
>>> Even in that case, if searching for [python str.rreplace] didn't turn up
>>> anything then chances are there was no proposal, which makes it a new idea
>>> and thus belongs on python-ideas. Basically the rule of thumb is anything
>>> considered new goes to python-ideas first.
>>>
>>
>>
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] str.rreplace

[Brett Cannon]

On Fri, Jan 24, 2014 at 12:46 PM, Ram Rachum  wrote:

> Okay, next time I'll ask on python-ideas. (I do hope that no one there
> will be angry that I'm posting a question there rather than an idea...)
>

Nope, no one will. Just phrase it as "is there something like a
str.rreplace? If not I think it would be useful because ...". The
assumption is that if you are asking if something exists then you would
like it to exist, in which case you should have a reason for wanting it.

-Brett


>
>
> On Fri, Jan 24, 2014 at 7:41 PM, Brett Cannon  wrote:
>
>>
>>
>>
>> On Fri, Jan 24, 2014 at 12:33 PM, Ram Rachum  wrote:
>>
>>> I knew it didn't exist by that name, but couldn't know whether there was
>>> another function that did the same thing or technique to make it not needed.
>>>
>>> So I couldn't know whether it's new or not, therefore I couldn't know
>>> whether it should be on python-ideas or not.
>>>
>>
>> So then you were simply wondering about its existence, for which you
>> should go to python-list or python-ideas first. Python-ideas exists
>> *explicitly* as a filter for this kind of question which is why people are
>> saying it should have gone there first (or to python-list).
>>
>> If you have any doubt as to whether a question should go here or not,
>> then err on the side of caution and post to python-ideas or python-list
>> first.
>>
>> -Brett
>>
>>
>>>
>>>
>>>
>>> On Fri, Jan 24, 2014 at 7:31 PM, Brett Cannon  wrote:
>>>



 On Fri, Jan 24, 2014 at 11:46 AM, Ram Rachum  wrote:

> You see, Antoine, *you* know that it's better asked on python-ideas
> because you know it doesn't exist in Python, therefore it's an idea for an
> addition. However, when a person like me asks this question, he does not
> know whether it exists or not, so he can't know whether he's proposing a
> new idea or whether it's something that exists under a different name or
> whether that's something that can't exist because of some unknown reason
> that the asker didn't think of.
>
> Now that I know it doesn't exist, I'll ask this on python-ideas.
>

 I think there might be a language issue here because you originally
 said "Why is there no str.rreplace in Python?" which shows you already
 knew it didn't exist. Did you mean to say you wanted to know *why* it
 didn't exist?

 Even in that case, if searching for [python str.rreplace] didn't turn
 up anything then chances are there was no proposal, which makes it a new
 idea and thus belongs on python-ideas. Basically the rule of thumb is
 anything considered new goes to python-ideas first.

>>>
>>>
>>
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python 3 marketing document?

[A.M. Kuchling]

On Fri, Jan 24, 2014 at 10:37:12AM -0600, Jesse Noller wrote:
> fwiw, I'm offering the keys/account/etc for getpython3.com to whomever
> has the time to keep it fresh and up to date.

I'd be interested.

--amk
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] str.rreplace

[Ethan Furman]

On 01/24/2014 09:19 AM, Ram Rachum wrote:

Hmm, on one hand I understand the need for the separation between python-dev 
and python-list, but on the other hand I
don't think python-list is a good place to discuss Python, the language.


[snip]


it's full of people asking about third-party Python packages, or asking newbie 
questions.


Yes, so imagine how happy we would be to see an actual Python the Language 
question there!  :)

Setting follow-up to Python List.

--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python 3 marketing document?

[Mark Lawrence]

On 24/01/2014 16:37, Jesse Noller wrote:

fwiw, I'm offering the keys/account/etc for getpython3.com to whomever
has the time to keep it fresh and up to date.



If I've ever heard of this I've forgotten about it.  How do we make it 
more prominent?


--
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.


Mark Lawrence

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] str.rreplace

[Wes Turner]

On Jan 24, 2014 11:43 AM, "Terry Reedy"  wrote:
>
> On 1/24/2014 12:19 PM, Ram Rachum wrote:
>>
>> Hmm, on one hand I understand the need for the separation between
>> python-dev and python-list, but on the other hand I don't think
>> python-list is a good place to discuss Python, the language.
>

Is there a link to this sort of information? (e.g. a page with group
descriptions)

(EDIT) http://www.python.org/community/lists/

>
> Python-list is the place for such discussions. Questions such as yours
are common. I have been reading it for almost 17 years.
>

Http://reddit.com/r/learnpython can also be helpful, though it only
supports markdown.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python 3 marketing document?

[Jesse Noller]

I'm giving AMK the keys to the kingdom right now:

AMK: Feel free to go nuts. Email me your public key

On Fri, Jan 24, 2014 at 12:01 PM, Mark Lawrence  wrote:
> On 24/01/2014 16:37, Jesse Noller wrote:
>>
>> fwiw, I'm offering the keys/account/etc for getpython3.com to whomever
>> has the time to keep it fresh and up to date.
>>
>
> If I've ever heard of this I've forgotten about it.  How do we make it more
> prominent?
>
> --
> My fellow Pythonistas, ask not what our language can do for you, ask what
> you can do for our language.
>
> Mark Lawrence
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/jnoller%40gmail.com
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] str.rreplace

[Terry Reedy]

On 1/24/2014 12:50 PM, Wes Turner wrote:

On Jan 24, 2014 11:43 AM, "Terry Reedy" mailto:tjre...@udel.edu>> wrote:
 >
 > On 1/24/2014 12:19 PM, Ram Rachum wrote:
 >>
 >> Hmm, on one hand I understand the need for the separation between
 >> python-dev and python-list, but on the other hand I don't think
 >> python-list is a good place to discuss Python, the language.
 >

Is there a link to this sort of information? (e.g. a page with group
descriptions)

(EDIT) http://www.python.org/community/lists/


mail.python.org, which redirects to
https://mail.python.org/mailman/listinfo

Python-list:
General discussion list for the Python programming language
Python-Dev  Python core developers
Python-ideasDiscussions of speculative Python language ideas


 > Python-list is the place for such discussions. Questions such as
yours are common. I have been reading it for almost 17 years.
 >

--
Terry Jan Reedy

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] str.rreplace

[Brian Curtin]

On Fri, Jan 24, 2014 at 11:40 AM, Mark Lawrence  wrote:
> On 24/01/2014 17:19, Ram Rachum wrote:
>>
>> Hmm, on one hand I understand the need for the separation between
>> python-dev and python-list, but on the other hand I don't think
>> python-list is a good place to discuss Python, the language.
>>
>> I now looked at the 17 most recent python-list threads. Out of them:
>>
>>   - 58% are about third-party packages.
>>   - 17% are off-topic (not even programming related)
>>   - 11% are 2-vs-3 discussions
>>   - 5% are job offers.
>>   - 5% (which is just one thread out of 17) is about Python the language.
>>
>
>
> I'm extremely impressed by your knowledge of statistics, it must have taken
> you many man years of effort to analyse all 17 threads in such detail.
>
>
>> So can you understand why someone would be reluctant to start a
>> discussion in python-list about Python the language there? Especially if
>> this is the same place where beginners might ask newbies questions about
>> Python? (So not only are actual Python questions just 5% of the content,
>> non-newbie questions are just a subset of that 5%.)
>>
>> it's full of people asking about third-party Python packages, or asking
>> newbie questions.
>>
>
> How terrible, fancy having the audacity to ask about third party packages or
> newbie questions on the *MAIN* Python mailing list.  There's yet another
> reason to bring back the death penalty in the UK.

Please adjust the tone of your messages if you are going to use this
mailing list.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] str.rreplace

[Mark Lawrence]

On 24/01/2014 22:44, Brian Curtin wrote:

On Fri, Jan 24, 2014 at 11:40 AM, Mark Lawrence  wrote:

On 24/01/2014 17:19, Ram Rachum wrote:


Hmm, on one hand I understand the need for the separation between
python-dev and python-list, but on the other hand I don't think
python-list is a good place to discuss Python, the language.

I now looked at the 17 most recent python-list threads. Out of them:

   - 58% are about third-party packages.
   - 17% are off-topic (not even programming related)
   - 11% are 2-vs-3 discussions
   - 5% are job offers.
   - 5% (which is just one thread out of 17) is about Python the language.




I'm extremely impressed by your knowledge of statistics, it must have taken
you many man years of effort to analyse all 17 threads in such detail.



So can you understand why someone would be reluctant to start a
discussion in python-list about Python the language there? Especially if
this is the same place where beginners might ask newbies questions about
Python? (So not only are actual Python questions just 5% of the content,
non-newbie questions are just a subset of that 5%.)

it's full of people asking about third-party Python packages, or asking
newbie questions.



How terrible, fancy having the audacity to ask about third party packages or
newbie questions on the *MAIN* Python mailing list.  There's yet another
reason to bring back the death penalty in the UK.


Please adjust the tone of your messages if you are going to use this
mailing list.



I'm sorry but I do not understand, please explain what is wrong with an 
extremely heavy dose of sarcasm.


--
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.


Mark Lawrence

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] str.rreplace

[Brian Curtin]

On Fri, Jan 24, 2014 at 4:50 PM, Mark Lawrence  wrote:
> On 24/01/2014 22:44, Brian Curtin wrote:
>>
>> On Fri, Jan 24, 2014 at 11:40 AM, Mark Lawrence 
>> wrote:
>>>
>>> On 24/01/2014 17:19, Ram Rachum wrote:


 Hmm, on one hand I understand the need for the separation between
 python-dev and python-list, but on the other hand I don't think
 python-list is a good place to discuss Python, the language.

 I now looked at the 17 most recent python-list threads. Out of them:

- 58% are about third-party packages.
- 17% are off-topic (not even programming related)
- 11% are 2-vs-3 discussions
- 5% are job offers.
- 5% (which is just one thread out of 17) is about Python the
 language.

>>>
>>>
>>> I'm extremely impressed by your knowledge of statistics, it must have
>>> taken
>>> you many man years of effort to analyse all 17 threads in such detail.
>>>
>>>
 So can you understand why someone would be reluctant to start a
 discussion in python-list about Python the language there? Especially if
 this is the same place where beginners might ask newbies questions about
 Python? (So not only are actual Python questions just 5% of the content,
 non-newbie questions are just a subset of that 5%.)

 it's full of people asking about third-party Python packages, or asking
 newbie questions.

>>>
>>> How terrible, fancy having the audacity to ask about third party packages
>>> or
>>> newbie questions on the *MAIN* Python mailing list.  There's yet another
>>> reason to bring back the death penalty in the UK.
>>
>>
>> Please adjust the tone of your messages if you are going to use this
>> mailing list.
>>
>
> I'm sorry but I do not understand, please explain what is wrong with an
> extremely heavy dose of sarcasm.

There's a real discussion going on and you're just responding to throw
around sarcasm. People aren't going to come to this list if you're
just going to give them snarky replies. It's not helping.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] str.rreplace

[Mark Lawrence]

On 24/01/2014 22:56, Brian Curtin wrote:

On Fri, Jan 24, 2014 at 4:50 PM, Mark Lawrence  wrote:

On 24/01/2014 22:44, Brian Curtin wrote:


On Fri, Jan 24, 2014 at 11:40 AM, Mark Lawrence 
wrote:


On 24/01/2014 17:19, Ram Rachum wrote:



Hmm, on one hand I understand the need for the separation between
python-dev and python-list, but on the other hand I don't think
python-list is a good place to discuss Python, the language.

I now looked at the 17 most recent python-list threads. Out of them:

- 58% are about third-party packages.
- 17% are off-topic (not even programming related)
- 11% are 2-vs-3 discussions
- 5% are job offers.
- 5% (which is just one thread out of 17) is about Python the
language.




I'm extremely impressed by your knowledge of statistics, it must have
taken
you many man years of effort to analyse all 17 threads in such detail.



So can you understand why someone would be reluctant to start a
discussion in python-list about Python the language there? Especially if
this is the same place where beginners might ask newbies questions about
Python? (So not only are actual Python questions just 5% of the content,
non-newbie questions are just a subset of that 5%.)

it's full of people asking about third-party Python packages, or asking
newbie questions.



How terrible, fancy having the audacity to ask about third party packages
or
newbie questions on the *MAIN* Python mailing list.  There's yet another
reason to bring back the death penalty in the UK.



Please adjust the tone of your messages if you are going to use this
mailing list.



I'm sorry but I do not understand, please explain what is wrong with an
extremely heavy dose of sarcasm.


There's a real discussion going on and you're just responding to throw
around sarcasm. People aren't going to come to this list if you're
just going to give them snarky replies. It's not helping.



Okay, I'll leave the snarky comments to the people who are authorised to 
be snarky.  How do you get on this list?  Is it any core dev, or are 
there more severe restrictions than that, for example do you have to be 
a member of the PSF, in which case I'd guess you can be very snarky 
without having a word said against you?


--
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.


Mark Lawrence

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] str.rreplace

[Brett Cannon]

On Fri, Jan 24, 2014 at 6:02 PM, Mark Lawrence wrote:

> On 24/01/2014 22:56, Brian Curtin wrote:
>
>> On Fri, Jan 24, 2014 at 4:50 PM, Mark Lawrence 
>> wrote:
>>
>>> On 24/01/2014 22:44, Brian Curtin wrote:
>>>

 On Fri, Jan 24, 2014 at 11:40 AM, Mark Lawrence <
 breamore...@yahoo.co.uk>
 wrote:

>
> On 24/01/2014 17:19, Ram Rachum wrote:
>
>>
>>
>> Hmm, on one hand I understand the need for the separation between
>> python-dev and python-list, but on the other hand I don't think
>> python-list is a good place to discuss Python, the language.
>>
>> I now looked at the 17 most recent python-list threads. Out of them:
>>
>> - 58% are about third-party packages.
>> - 17% are off-topic (not even programming related)
>> - 11% are 2-vs-3 discussions
>> - 5% are job offers.
>> - 5% (which is just one thread out of 17) is about Python the
>> language.
>>
>>
>
> I'm extremely impressed by your knowledge of statistics, it must have
> taken
> you many man years of effort to analyse all 17 threads in such detail.
>
>
>  So can you understand why someone would be reluctant to start a
>> discussion in python-list about Python the language there? Especially
>> if
>> this is the same place where beginners might ask newbies questions
>> about
>> Python? (So not only are actual Python questions just 5% of the
>> content,
>> non-newbie questions are just a subset of that 5%.)
>>
>> it's full of people asking about third-party Python packages, or
>> asking
>> newbie questions.
>>
>>
> How terrible, fancy having the audacity to ask about third party
> packages
> or
> newbie questions on the *MAIN* Python mailing list.  There's yet
> another
> reason to bring back the death penalty in the UK.
>


 Please adjust the tone of your messages if you are going to use this
 mailing list.


>>> I'm sorry but I do not understand, please explain what is wrong with an
>>> extremely heavy dose of sarcasm.
>>>
>>
>> There's a real discussion going on and you're just responding to throw
>> around sarcasm. People aren't going to come to this list if you're
>> just going to give them snarky replies. It's not helping.
>>
>>
> Okay, I'll leave the snarky comments to the people who are authorised to
> be snarky.  How do you get on this list?  Is it any core dev, or are there
> more severe restrictions than that, for example do you have to be a member
> of the PSF, in which case I'd guess you can be very snarky without having a
> word said against you?


I suspect Brian's point is sarcasm is fine in moderation. I'm sure we have
all had incidences online where sarcasm was not understood and someone took
it the wrong way. And with this list being international the chance of
something not catching something as sarcastic just goes up. So sarcasm is
fine, but keep it on the lighter side is all.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] str.rreplace

[Nick Coghlan]

On 25 Jan 2014 09:46, "Brett Cannon"  wrote:
> On Fri, Jan 24, 2014 at 6:02 PM, Mark Lawrence 
wrote:
>>>
>>
>> Okay, I'll leave the snarky comments to the people who are authorised to
be snarky.  How do you get on this list?  Is it any core dev, or are there
more severe restrictions than that, for example do you have to be a member
of the PSF, in which case I'd guess you can be very snarky without having a
word said against you?
>
>
> I suspect Brian's point is sarcasm is fine in moderation. I'm sure we
have all had incidences online where sarcasm was not understood and someone
took it the wrong way. And with this list being international the chance of
something not catching something as sarcastic just goes up. So sarcasm is
fine, but keep it on the lighter side is all.

I personally draw the line as so:

- is my draft post *just* snark? Then I delete it rather than posting -
such posts never further the discussion, increase the level of noise on the
list, and generally waste the time of other list subscribers solely for
some momentary emotional satisfaction on my part. If I really feel the need
to vent, then I'll send the unhelpful post directly to a friend rather than
to the list. This is the kind of post that has no place on any of the core
development lists.

- is there a snarky side comment in an otherwise constructive post? Then
I'll usually take it out anyway, since such comments still usually hinder
communication rather than helping it, and we already have enough inherent
barriers to effective communication due to a relative lack of knowledge of
each other's backgrounds and experience. However, if I'm genuinely
irritated, I'll sometimes leave them in - I'm not a saint, and a snarky
comment that indicates "I am annoyed by this thread or situation" is a
vastly different thing from a snarky *post* that says to someone else "your
post was bad and you should feel bad".

- there are other times (fortunately rare), when I consider it necessary to
express genuine concern or anger. My main tool for dealing with such posts
in the most constructive manner possible is to find every occurrence of the
pronoun "you" (or other people's names) and figure out how to replace it
with the pronoun "I". The purpose of such rephrasing is to help ensure the
post is a constructive one expressing my concerns and sharing my
impressions and experience rather than a destructive one that causes the
recipients to become defensive, because once we dig in our heels and start
defending our positions out of ego rather than reason, then the opportunity
for a meaningful, productive discussion is lost.

So, a snarky side comment or two in otherwise constructive post? Not
preferred, but usually acceptable. A post consisting of nothing but snark?
Not acceptable - either don't post it, or send it to a trusted friend
off-list in order to vent.

In this specific case, our general communication about the different
purposes of the core lists *isn't* particularly good, so it's entirely
expected that we'll still get the occasional post to python-dev that is
better directed to a different list. That's why everyone gets a free pass
to asking one or two inappropriate questions on python-dev, since it isn't
always clear to them that the question is off-topic. The appropriate
response is to politely explain the purposes of the different lists and
redirect them to the correct one.

Cheers,
Nick.

>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] str.rreplace

[Steven D'Aprano]

On Sat, Jan 25, 2014 at 10:41:05AM +1000, Nick Coghlan wrote:

> In this specific case, our general communication about the different
> purposes of the core lists *isn't* particularly good,

Nick, I beg to differ: I think that our communication in this regard 
actually is quite reasonable. Before signing up to Python-Dev via the 
website, one cannot help but see right at the top of the page:

Do not post general Python questions to this list. For help with 
Python please see the Python help page.

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

Although perhaps a link directly to the python-list mailing list 
as well wouldn't go astray.

> so it's entirely
> expected that we'll still get the occasional post to python-dev that is
> better directed to a different list. That's why everyone gets a free pass
> to asking one or two inappropriate questions on python-dev, since it isn't
> always clear to them that the question is off-topic.

I agree with the conclusion, but not the reason. We should allow people 
a free pass for small errors, because we would appreciate such a free 
pass for small errors ourselves. To err is human, to forgive is humane, 
and a little bit of kindness helps grease the wheels of civilized 
discourse.

(Also, there sometimes are grey areas where it isn't clear whether a 
question is on-topic or not. However, "Is there a version of str.replace 
that works from the right?" is not in that grey area.)

What annoyed me most about Ram's thread is not that he made the mistake 
in the first place, but that when gently corrected, he choose to argue 
and give spurious reasons for why this was the right place to ask. 
Still, I think Mark's overly-aggressive use of sarcasm in an otherwise 
content-less post was out of proportion to the magnitude of Ram's 
transgression.



-- 
Steven
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] str.rreplace

[Nick Coghlan]

On 25 January 2014 11:14, Steven D'Aprano  wrote:
> On Sat, Jan 25, 2014 at 10:41:05AM +1000, Nick Coghlan wrote:
>
>> In this specific case, our general communication about the different
>> purposes of the core lists *isn't* particularly good,
>
> Nick, I beg to differ: I think that our communication in this regard
> actually is quite reasonable. Before signing up to Python-Dev via the
> website, one cannot help but see right at the top of the page:
>
> Do not post general Python questions to this list. For help with
> Python please see the Python help page.
>
> https://mail.python.org/mailman/listinfo/python-dev
>
> Although perhaps a link directly to the python-list mailing list
> as well wouldn't go astray.

I believe you can currently post without subscribing, though.

It isn't that the relevant information isn't available (it is:
http://docs.python.org/devguide/communication.html), it's that there
are lots of ways to miss that ifnformation, so there's always going to
be the occasional misdirected question.

And yes, I agree that responding to gentle redirection with "I still
think this is the right place for my question" is not an appropriate
way for anyone to behave.

Moving on to practical matters: perhaps we should ensure a link to
that communications page is included in the list descriptions and
automated footers for at least python-dev and python-ideas, and also
that we update it to include a link to the PSF code of conduct page?
(The python-ideas footer already links directly to the CoC)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Quick poll: should help() show bound arguments?

[Larry Hastings]

(Quick, because apparently nobody reads the long ones!)

In Python 3.3:

>>> class C:
   ...def foo(self, a):  pass
   ...
>>> c = C()
>>> help(c.foo)

shows you the signature "foo(self, a)".  As in, it claims it accepts two 
parameters.  The function actually only accepts one parameter, because 
"self" has already been bound.  inspect.signature gets this right:


>>> import inspect
>>> str(inspect.signature(c.foo))
   '(a)'

but inspect.getfullargspec does not:

>>> inspect.getfullargspec(c.foo)
   FullArgSpec(args=['self', 'a'], varargs=None, varkw=None,
   defaults=None, kwonlyargs=[], kwonlydefaults=None, annotations={})


help() gets its text from pydoc.  pydoc uses inspect.getfullargspec to 
produce the signature.


When I added support for introspection on builtins, I wanted help() to 
show their signature too.  But inspect.getfullargspec doesn't support 
introspection on builtins.  So I had to use inspect.signature.  Which 
means the behavior is inconsistent: help() on a method of an instance of 
a builtin class *doesn't* show "self".



FYI, the relevant issues:

   help(instance_of_builtin_class.method) does not display self

   http://bugs.python.org/issue20379

   inspect.getfullargspec should use __siganture__

   http://bugs.python.org/issue17481


What should it be?

A) pydoc and help() should not show bound parameters in the signature, 
like inspect.signature.
B) pydoc and help() should show bound parameters in the signature, like 
inspect.getfullargspec.


I'll tally the results if there's interest.  I'd assume a "vote for A" = 
+1 on A and -1 on B.  You can express your vote numerically if you 
like.  I'm voting for A.



And yes, that was short for me,


//arry/
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Quick poll: should help() show bound arguments?

[Zachary Ware]

On Fri, Jan 24, 2014 at 10:07 PM, Larry Hastings  wrote:
>
> (Quick, because apparently nobody reads the long ones!)
>
> In Python 3.3:
>
 class C:
> ...def foo(self, a):  pass
> ...
 c = C()
 help(c.foo)
>
> shows you the signature "foo(self, a)".  As in, it claims it accepts two
> parameters.  The function actually only accepts one parameter, because
> "self" has already been bound.  inspect.signature gets this right:
>
 import inspect
 str(inspect.signature(c.foo))
> '(a)'
>
> but inspect.getfullargspec does not:
>
 inspect.getfullargspec(c.foo)
> FullArgSpec(args=['self', 'a'], varargs=None, varkw=None, defaults=None,
> kwonlyargs=[], kwonlydefaults=None, annotations={})
>
>
> help() gets its text from pydoc.  pydoc uses inspect.getfullargspec to
> produce the signature.
>
> When I added support for introspection on builtins, I wanted help() to show
> their signature too.  But inspect.getfullargspec doesn't support
> introspection on builtins.  So I had to use inspect.signature.  Which means
> the behavior is inconsistent: help() on a method of an instance of a builtin
> class *doesn't* show "self".
>
>
> FYI, the relevant issues:
>
> help(instance_of_builtin_class.method) does not display self
>
> http://bugs.python.org/issue20379
>
> inspect.getfullargspec should use __siganture__
>
> http://bugs.python.org/issue17481
>
>
> What should it be?
>
> A) pydoc and help() should not show bound parameters in the signature, like
> inspect.signature.
> B) pydoc and help() should show bound parameters in the signature, like
> inspect.getfullargspec.
>
> I'll tally the results if there's interest.  I'd assume a "vote for A" = +1
> on A and -1 on B.  You can express your vote numerically if you like.  I'm
> voting for A.
>

I vote A: it makes sense (though B does too, to an extent), and the
patch to make help() consistent for Python and C implemented methods
is simply removing two lines from pydoc.  I'm not sure how convoluted
it might become to make it work the other way.

-- 
Zach
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Quick poll: should help() show bound arguments?

[Steven D'Aprano]

On Fri, Jan 24, 2014 at 08:07:43PM -0800, Larry Hastings wrote:
> 
> (Quick, because apparently nobody reads the long ones!)
> 
> In Python 3.3:
> 
> >>> class C:
>...def foo(self, a):  pass
>...
> >>> c = C()
> >>> help(c.foo)
> 
> shows you the signature "foo(self, a)".

That matches the function declaration as defined right there in the 
class.


> As in, it claims it accepts two 
> parameters.  The function actually only accepts one parameter, because 
> "self" has already been bound.

No, that's wrong. The *function* C.foo accepts two parameters, self and 
a, exactly as declared. The *method* c.foo accepts only one.


> inspect.signature gets this right:
> 
> >>> import inspect
> >>> str(inspect.signature(c.foo))
>'(a)'
> 
> but inspect.getfullargspec does not:
> 
> >>> inspect.getfullargspec(c.foo)
>FullArgSpec(args=['self', 'a'], varargs=None, varkw=None,
>defaults=None, kwonlyargs=[], kwonlydefaults=None, annotations={})

That's arguable. Should inspect give the argument spec of the method 
object or the function object? I can see arguments for both. 
Backwards-compatibility argues against changing either, though.

help() is another story. Since help() is documentation aimed at the 
end-user, we can change it without worrying about backward 
compatibility. Ideally, help() ought to distingush between the two 
cases. I see that it already does, but not very well.

help(c.foo) in Python 3.3 gives:

Help on method foo in module __main__:
 
foo(self, a) method of __main__.C instance


while help(C.foo) gives:

Help on function foo in module __main__:

foo(self, a)



I think in the bound method case, it should drop the "self":

Help on method foo in module __main__:

foo(a) method of __main__.C instance


and in the function (previously: unbound method) case, it should show 
the "self" and the class:

Help on function foo in module __main__:

foo(self, a) method of class __main__.C

although I'm not sure how that second one is possible, now that unbound 
methods are gone and C.foo returns a plain function.

(Hmmm, perhaps getting rid of unbound methods was a mistake...)


> A) pydoc and help() should not show bound parameters in the signature, 
> like inspect.signature.
> B) pydoc and help() should show bound parameters in the signature, like 
> inspect.getfullargspec.


Provided they are described as *methods* rather than *functions*, bound 
methods should not show self. Likewise for classmethod and cls. That is, 
I'm voting +1 on A provided help() doesn't confuse methods and 
functions.


-- 
Steven
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] Cron /home/docs/build-devguide

[Benjamin Peterson]

On Fri, Jan 24, 2014, at 08:45 PM, Cron Daemon wrote:
> Could not find platform independent libraries 
> Could not find platform dependent libraries 
> Consider setting $PYTHONHOME to [:]
> 'import site' failed; use -v for traceback
> Traceback (most recent call last):
>   File "/data/hg/sphinx-env/bin/sphinx-build", line 5, in 
> from pkg_resources import load_entry_point
> ImportError: No module named pkg_resources

I recreated the sphinx virtualenv on dinsdale, so hopefully this will be
fixed now.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Quick poll: should help() show bound arguments?

[Nick Coghlan]

On 25 January 2014 14:36, Steven D'Aprano  wrote:
> On Fri, Jan 24, 2014 at 08:07:43PM -0800, Larry Hastings wrote:

>> A) pydoc and help() should not show bound parameters in the signature,
>> like inspect.signature.
>> B) pydoc and help() should show bound parameters in the signature, like
>> inspect.getfullargspec.
>
> Provided they are described as *methods* rather than *functions*, bound
> methods should not show self. Likewise for classmethod and cls. That is,
> I'm voting +1 on A provided help() doesn't confuse methods and
> functions.

+1 from me for fixing the signature help() and pydoc report for bound
methods that are reported as such.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Quick poll: should help() show bound arguments?

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/24/2014 11:07 PM, Larry Hastings wrote:
> A) pydoc and help() should not show bound parameters in the signature,
>  like inspect.signature. B) pydoc and help() should show bound
> parameters in the signature, like inspect.getfullargspec.


+1 for A:  it is how you would actually call the object on which 'help()'
is being called.  The fact that self will be passed silently is
irrelevant to the caller.


Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlLjU4UACgkQ+gerLs4ltQ48SQCg0zMZseKV3EZ/0pRkc5ngt2tb
aFMAn0Vhze2wMEim6Vf7F1fvlh+j3PJ/
=Mx/i
-END PGP SIGNATURE-

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] lambda (x, y):

[Greg Ewing]

Brett Cannon wrote:


On Fri, Jan 24, 2014 at 10:50 AM, Ram Rachum > wrote:


lambda (x, y): whatever

http://python.org/dev/peps/pep-3113/


Part of the rationale in that PEP is that argument unpacking
can always be replaced by an explicitly named argument and
an unpacking assignment. No mention is made of the fact that
you can't do this in a lambda, giving the impression that
lambdas are deemed second-class citizens that are not worth
consideration.

The author was clearly aware of the issue, since a strategy
is suggested for translation of lambdas by 2to3:

   lambda (x, y): x + y --> lambda x_y: x_y[0] + x_y[1]

That's a bit on the ugly side for human use, though.
An alternative would be

   lambda xy: (lambda x, y: x + y)(*xy)

Whether that's any better is a matter of opinion.

--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] lambda (x, y):

[Nick Coghlan]

On 25 January 2014 15:41, Greg Ewing  wrote:
> Brett Cannon wrote:
>>
>>
>> On Fri, Jan 24, 2014 at 10:50 AM, Ram Rachum > > wrote:
>>
>> lambda (x, y): whatever
>>
>> http://python.org/dev/peps/pep-3113/
>
>
> Part of the rationale in that PEP is that argument unpacking
> can always be replaced by an explicitly named argument and
> an unpacking assignment. No mention is made of the fact that
> you can't do this in a lambda, giving the impression that
> lambdas are deemed second-class citizens that are not worth
> consideration.

Given that lambdas only just escaped being removed entirely from the
language in Python 3, that impression isn't wrong.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] lambda (x, y):

[Serhiy Storchaka]

25.01.14 07:41, Greg Ewing написав(ла):

Brett Cannon wrote:


On Fri, Jan 24, 2014 at 10:50 AM, Ram Rachum mailto:r...@rachum.com>> wrote:

lambda (x, y): whatever

http://python.org/dev/peps/pep-3113/


Part of the rationale in that PEP is that argument unpacking
can always be replaced by an explicitly named argument and
an unpacking assignment. No mention is made of the fact that
you can't do this in a lambda, giving the impression that
lambdas are deemed second-class citizens that are not worth
consideration.

The author was clearly aware of the issue, since a strategy
is suggested for translation of lambdas by 2to3:

lambda (x, y): x + y --> lambda x_y: x_y[0] + x_y[1]

That's a bit on the ugly side for human use, though.
An alternative would be

lambda xy: (lambda x, y: x + y)(*xy)

Whether that's any better is a matter of opinion.


There is open issue for this:

http://bugs.python.org/issue16094

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Argument Clinic: what to do with builtins with non-standard signatures?

[Nick Coghlan]

On 25 January 2014 01:07, Larry Hastings  wrote:
> I'm sorting the problems we see into four rough categories.
>
> a) Functions where there's a static Python value that behaves
>identically to not passing in that parameter (aka "the NULL problem")
>
>Possible Solutions:
>  0) Do nothing, don't convert the function.
>  1) Use that clever static value as the default.

For this case, I think option 1) is better, as there's no externally
visible change in semantics, just a change to the internal
implementation details.

> b) Functions where there's no static Python value that behaves identically
> to
>not passing in that parameter (aka "the dynamic default problem")
>
>Possible solutions:
>  0) Do nothing, don't convert the function.
>  1) Use a magic value as None.  Preferably of the same type as the
> function accepts, but failing that use None.  If they pass in
> the magic value use the previous default value.  Guido himself
> suggested this in
>  2) Use an Argument Clinic "optional group".  This only works for
> functions that don't support keyword arguments.  Also, I hate
> this, because "optional groups" are not expressable in Python
> syntax, so these functions automatically have invalid signatures.

I'm inclined to say "leave these for now, we'll fix them in 3.5".
They're going to be hard to convert without altering their semantics,
which we shouldn't be doing at this stage of the release cycle.
There's going to be follow up work in 3.5 anyway, as I think we should
continue with PEP 457 to make __text_signature__ a public API and add
optional group support to inspect.Signature.

> c) Functions that accept an 'int' when they mean 'boolean' (aka the
>"ints instead of bools" problem)
>
>Solution:
>  1) Use "bool".
>  2) Use "int", and I'll go relax Argument Clinic so they
> can use bool values as defaults for int parameters.

If the temptation is to use True or False as the default, then I think
that's a clear argument that these should be accepting "bool".
However, expanding the accepted types is also clearly a new feature
that would need a "versionchanged" in the docs for all affected
functions, so I think these changes also belong in the "conversion
implies semantic changes, so leave until 3.5" category.

> d) Functions with behavior that deliberately defy being expressed as a
>Python signature (aka the "untranslatable signature" problem)
>
>Example:
>  itertools.repeat(), which behaves differently depending on whether
>  "times" is supplied as a positional or keyword argument.  (If
>  "times" is <0, and was supplied via position, the function yields
>  0 times. If "times" is <0, and was supplied via keyword, the
>  function yields infinitely-many times.)
>
>Solution:
>  0) Do nothing, don't convert the function.
>  1) Change the signature until it is Python compatible.  This new
> signature *must* accept a superset of the arguments accepted
> by the existing signature.  (This is being discussed right
> now in issue #19145.)

For these, I think we should respect the release cycle and leave them until 3.5.

Python has survived for a couple of decades with broken introspection
for builtins and extension modules, we'll survive another release that
still exhibits a subset of the problem :)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] Cron /home/docs/build-devguide

[Georg Brandl]

Am 25.01.2014 05:49, schrieb Benjamin Peterson:
> On Fri, Jan 24, 2014, at 08:45 PM, Cron Daemon wrote:
>> Could not find platform independent libraries 
>> Could not find platform dependent libraries 
>> Consider setting $PYTHONHOME to [:]
>> 'import site' failed; use -v for traceback
>> Traceback (most recent call last):
>>   File "/data/hg/sphinx-env/bin/sphinx-build", line 5, in 
>> from pkg_resources import load_entry_point
>> ImportError: No module named pkg_resources
> 
> I recreated the sphinx virtualenv on dinsdale, so hopefully this will be
> fixed now.

Thanks, this somehow slipped by me.

Georg

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com