Re: [Python-Dev] Python 3 marketing document?
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?
On Thu, Jan 23, 2014 at 10:48 PM, Dan Stromberg drsali...@gmail.com 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?
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 defaulted to the length
Re: [Python-Dev] Argument Clinic: what to do with builtins with non-standard signatures?
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):
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):
On Fri, Jan 24, 2014 at 10:50 AM, Ram Rachum r...@rachum.com 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):
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?
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/https://pypi.python.org/pypi/backports.ssl_match_hostname backports.ssl_match_hostnamehttps://pypi.python.org/pypi/backports.ssl_match_hostname http:// http://docs.python.org/3.4/library/asyncio.htmldocs.python.orghttp://docs.python.org/3.4/library/asyncio.html /3.4/library/ http://docs.python.org/3.4/library/asyncio.htmlasyncio.htmlhttp://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 drsali...@gmail.com 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
On 24 January 2014 03:06, Stephen J. Turnbull step...@xemacs.org 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
On 23 January 2014 08:37, Stephen J. Turnbull step...@xemacs.org 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?
-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 compatibility is not feasible for some reason, then I would favor the following: 2) Deprecate the manky builtin, and leave it
Re: [Python-Dev] Argument Clinic: what to do with builtins with non-standard signatures?
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
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
On Sat, Jan 25, 2014 at 3:38 AM, Antoine Pitrou solip...@pitrou.net wrote: On Fri, 24 Jan 2014 18:32:17 +0200 Ram Rachum r...@rachum.com 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?
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?
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 wes.tur...@gmail.com 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 drsali...@gmail.com 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
On Fri, 24 Jan 2014 18:32:17 +0200 Ram Rachum r...@rachum.com 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
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 solip...@pitrou.net wrote: On Fri, 24 Jan 2014 18:32:17 +0200 Ram Rachum r...@rachum.com 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
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
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 r...@rachum.com 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 On Jan 24, 2014 10:37 AM, Jesse Noller jnol...@gmail.com 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 wes.tur...@gmail.com 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 drsali...@gmail.com 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
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
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
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 tjre...@udel.edu 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
On Fri, Jan 24, 2014 at 11:46 AM, Ram Rachum r...@rachum.com 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
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 br...@python.org wrote: On Fri, Jan 24, 2014 at 11:46 AM, Ram Rachum r...@rachum.com 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
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
On Fri, Jan 24, 2014 at 12:33 PM, Ram Rachum r...@rachum.com 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 br...@python.org wrote: On Fri, Jan 24, 2014 at 11:46 AM, Ram Rachum r...@rachum.com 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
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
On Sat, Jan 25, 2014 at 4:19 AM, Ram Rachum r...@rachum.com 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
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 br...@python.org wrote: On Fri, Jan 24, 2014 at 12:33 PM, Ram Rachum r...@rachum.com 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 br...@python.org wrote: On Fri, Jan 24, 2014 at 11:46 AM, Ram Rachum r...@rachum.com 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
On Fri, Jan 24, 2014 at 12:46 PM, Ram Rachum r...@rachum.com 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 br...@python.org wrote: On Fri, Jan 24, 2014 at 12:33 PM, Ram Rachum r...@rachum.com 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 br...@python.org wrote: On Fri, Jan 24, 2014 at 11:46 AM, Ram Rachum r...@rachum.com 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?
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
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?
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
On Jan 24, 2014 11:43 AM, Terry Reedy 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/ 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?
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 breamore...@yahoo.co.uk 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
On 1/24/2014 12:50 PM, Wes Turner wrote: On Jan 24, 2014 11:43 AM, Terry Reedy tjre...@udel.edu 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
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. ___ 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
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. -- 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
On Fri, Jan 24, 2014 at 4:50 PM, Mark Lawrence breamore...@yahoo.co.uk 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. ___ 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
On 24/01/2014 22:56, Brian Curtin wrote: On Fri, Jan 24, 2014 at 4:50 PM, Mark Lawrence breamore...@yahoo.co.uk 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? -- 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
On Fri, Jan 24, 2014 at 6:02 PM, Mark Lawrence breamore...@yahoo.co.ukwrote: On 24/01/2014 22:56, Brian Curtin wrote: On Fri, Jan 24, 2014 at 4:50 PM, Mark Lawrence breamore...@yahoo.co.uk 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
On 25 Jan 2014 09:46, Brett Cannon br...@python.org wrote: On Fri, Jan 24, 2014 at 6:02 PM, Mark Lawrence breamore...@yahoo.co.uk 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
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
On 25 January 2014 11:14, Steven D'Aprano st...@pearwood.info 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?
(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?
On Fri, Jan 24, 2014 at 10:07 PM, Larry Hastings la...@hastings.org 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?
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 docs@dinsdale /home/docs/build-devguide
On Fri, Jan 24, 2014, at 08:45 PM, Cron Daemon wrote: Could not find platform independent libraries prefix Could not find platform dependent libraries exec_prefix Consider setting $PYTHONHOME to prefix[:exec_prefix] 'import site' failed; use -v for traceback Traceback (most recent call last): File /data/hg/sphinx-env/bin/sphinx-build, line 5, in module 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?
On 25 January 2014 14:36, Steven D'Aprano st...@pearwood.info 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?
-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 Designhttp://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):
Brett Cannon wrote: On Fri, Jan 24, 2014 at 10:50 AM, Ram Rachum r...@rachum.com 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. -- 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):
On 25 January 2014 15:41, Greg Ewing greg.ew...@canterbury.ac.nz wrote: Brett Cannon wrote: On Fri, Jan 24, 2014 at 10:50 AM, Ram Rachum r...@rachum.com 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. 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):
25.01.14 07:41, Greg Ewing написав(ла): Brett Cannon wrote: On Fri, Jan 24, 2014 at 10:50 AM, Ram Rachum r...@rachum.com 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?
On 25 January 2014 01:07, Larry Hastings la...@hastings.org 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 docs@dinsdale /home/docs/build-devguide
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 prefix Could not find platform dependent libraries exec_prefix Consider setting $PYTHONHOME to prefix[:exec_prefix] 'import site' failed; use -v for traceback Traceback (most recent call last): File /data/hg/sphinx-env/bin/sphinx-build, line 5, in module 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
