26.01.14 01:10, Christian Heimes написав(ла):
Coverity has detected an issue in this commit:
Thank you. This is false positive detection.
http://bugs.python.org/issue20394.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/m
On Sat, Jan 25, 2014, at 07:04 PM, Nick Coghlan wrote:
> Which suggests that the Google web crawler *is* spidering the dev
> docs, which we generally don't want :P
I've now added a robots.txt to disallow crawling /dev.
___
Python-Dev mailing list
Pytho
On 1/25/2014 10:37 AM, Larry Hastings wrote:
On 01/25/2014 07:26 AM, Nick Coghlan wrote:
However, you've indicated that adding varargs support is going to take
you quite a bit of work, so postponing it is an option definitely
worth considering at this point in the release cycle.
It's worth con
On 26 January 2014 12:30, Raymond Hettinger wrote:
>
> On Jan 25, 2014, at 5:29 AM, Ezio Melotti wrote:
>
> Nick also suggested to document
> our deprecation policy in PEP 5 (Guidelines for Language Evolution:
> http://www.python.org/dev/peps/pep-0005/ ).
>
>
> Here's a few thoughts on deprecatio
I think subdomains need there own robots.txt which docs.python.org nor
docs.python.org/(2 or 3)/ have.
and http://python.org/robots.txt (below) seems a little sparse.
For sure /dev/ is not blocked
# Directions for robots. See this URL:
# http://www.robotstxt.org/wc/norobots.html
# for a descript
On 26 January 2014 05:05, Benjamin Peterson wrote:
>
>
> On Sat, Jan 25, 2014, at 10:55 AM, Vincent Davis wrote:
>> On Sat, Jan 25, 2014 at 10:12 AM, Benjamin Peterson
>> wrote:
>>
>> > Internal links with no version redirect to the Python 2 version for
>> > backwards compatibility reasons.
>> >
>
On Jan 25, 2014, at 4:01 PM, Brett Cannon wrote:
> As the author of the PEP and I can say that `lambda (x, y): x + y` can just
> as easily be expressed as `lambda x, y: x + y` and then be called by using
> *args in the argument list. Anything that gets much fancier typically calls
> for a def
On Jan 25, 2014, at 5:29 AM, Ezio Melotti wrote:
> Nick also suggested to document
> our deprecation policy in PEP 5 (Guidelines for Language Evolution:
> http://www.python.org/dev/peps/pep-0005/ ).
Here's a few thoughts on deprecations:
* If we care at all about people moving to Python 3, the
On Sat, Jan 25, 2014 at 6:28 PM, Antoine Pitrou wrote:
> Is there a reason to have separate "importlib" (toplevel) and
> "importlib.util" namespaces?
As to why they are separate, you'll need to ask Brett. I believe it's
meant to keep the top namespace as small as possible.
Regarding this change
On 01/25/2014 04:34 AM, Chris Angelico wrote:
On Sat, Jan 25, 2014 at 3:07 PM, Larry Hastings wrote:
What should it be?
A) pydoc and help() should not show bound parameters in the signature, like
inspect.signature.
Vote for A. As far as I'm concerned, all these foo are equally
callable and
On Sat, 25 Jan 2014 23:37:49 +0100 (CET)
eric.snow wrote:
> http://hg.python.org/cpython/rev/665f1ba77b57
> changeset: 88710:665f1ba77b57
> user:Eric Snow
> date:Sat Jan 25 15:32:46 2014 -0700
> summary:
> Issue 19944: Fix importlib.find_spec() so it imports parents as needed.
On Sat, Jan 25, 2014 at 8:29 AM, Ezio Melotti wrote:
> Hi,
> a couple of years ago I suggested to define and document our
> deprecation policy in this thread:
> https://mail.python.org/pipermail/python-dev/2011-October/114199.html
> I didn't receive many replies and eventually nothing was done.
>
On Sat, Jan 25, 2014 at 12:41 AM, Greg Ewing wrote:
> Brett Cannon wrote:
>
>>
>> On Fri, Jan 24, 2014 at 10:50 AM, Ram Rachum > 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 unpac
On 25.01.2014 10:58, serhiy.storchaka wrote:
> http://hg.python.org/cpython/rev/d4099b8a7d0f
> changeset: 88687:d4099b8a7d0f
> user:Serhiy Storchaka
> date:Sat Jan 25 11:57:59 2014 +0200
> summary:
> Issue #20133: The audioop module now uses Argument Clinic.
>
> files:
> Mod
On Sat, 25 Jan 2014 15:02:56 +0100 (CET)
victor.stinner wrote:
> +
> +@tasks.coroutine
> +def wait():
> +loop = self.loop
> +calls.append(loop._run_once_counter)
> +yield from tasks.sleep(loop.granularity * 10, loop=loop)
> +calls.app
On Sat, Jan 25, 2014, at 10:55 AM, Vincent Davis wrote:
> On Sat, Jan 25, 2014 at 10:12 AM, Benjamin Peterson
> wrote:
>
> > Internal links with no version redirect to the Python 2 version for
> > backwards compatibility reasons.
> >
>
> On Sat, Jan 25, 2014 at 10:26 AM, Georg Brandl wrote:
>
On 01/25/2014 05:29 AM, Ezio Melotti wrote:
a couple of years ago I suggested to define and document our
deprecation policy
+1
--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscri
25.01.14 18:26, Georg Brandl написав(ла):
Am 25.01.2014 17:12, schrieb Benjamin Peterson:
On Sat, Jan 25, 2014, at 05:47 AM, Vincent Davis wrote:
When I do a google search the version numbers are mismatched with the
linked page (or redirected).
For example search for "python counter" I get the
Am 25.01.2014 17:12, schrieb Benjamin Peterson:
> On Sat, Jan 25, 2014, at 05:47 AM, Vincent Davis wrote:
>> When I do a google search the version numbers are mismatched with the
>> linked page (or redirected).
>> For example search for "python counter" I get the following results. (see
>> attachme
On Sat, Jan 25, 2014, at 05:47 AM, Vincent Davis wrote:
> When I do a google search the version numbers are mismatched with the
> linked page (or redirected).
> For example search for "python counter" I get the following results. (see
> attachment)
> It seems like the website is redirecting incorre
On Jan 24, 2014 9:13 PM, "Nick Coghlan" wrote:
>
> On 25 January 2014 11:14, Steven D'Aprano wrote:
> > On Sat, Jan 25, 2014 at 10:41:05AM +1000, Nick Coghlan wrote:
> >
> >> In this specific case, our general communication about the different
> >> purposes of the core lists *isn't* particularly
On 01/25/2014 07:26 AM, Nick Coghlan wrote:
However, you've indicated that adding varargs support is going to take
you quite a bit of work, so postponing it is an option definitely
worth considering at this point in the release cycle.
It's worth considering. I'm estimating it's about 1.5 days'
On 25 January 2014 22:19, Larry Hastings wrote:
> 1) New policy for what can and cannot be converted during the Derby
> The new policy for conversion work for Python 3.4:
>
> We may only convert functions that have signatures that we can represent
> 100% accurately in an inspect.Signature object.
On 25 January 2014 19:46, Stefan Behnel wrote:
> FWIW, Cython knows a type called "bint" that is identical to a C int except
> that it automatically coerces to and from a Python boolean value (using
> truth testing). Seems to match the use case of the "p" that was added to
> CPython's arg parsing
On Sat, 25 Jan 2014 05:42:58 -0800
Larry Hastings wrote:
> On 01/25/2014 05:37 AM, Antoine Pitrou wrote:
> > Speaking of which, I think asking for votes before all arguments have
> > been made is counter-productive.
>
> Sorry, I didn't realize there was an established protocol for this.
No, the
On 01/25/2014 05:37 AM, Antoine Pitrou wrote:
Speaking of which, I think asking for votes before all arguments have
been made is counter-productive.
Sorry, I didn't realize there was an established protocol for this.
//arry/
___
Python-Dev mailing l
On Fri, 24 Jan 2014 20:07:43 -0800
Larry Hastings wrote:
>
> A) pydoc and help() should not show bound parameters in the signature,
> like inspect.signature.
-1 from me. The problem is this will make help(c.foo) inconsistent with
help(c) and help(C), and is bound to confuse newcomers.
Speaking
On 01/25/2014 03:34 AM, Anders J. Munch wrote:
Larry Hastings wrote:
inspect.signature gets this right:
>>> import inspect
>>> str(inspect.signature(c.foo))
'(a)'
Not always.
: Python 3.4.0b2+ (default:32f9e0ae23f7, Jan 18 2014, 13:56:31)
: [GCC 4.2.1 Compatible Apple LLVM 4.2
Hi,
a couple of years ago I suggested to define and document our
deprecation policy in this thread:
https://mail.python.org/pipermail/python-dev/2011-October/114199.html
I didn't receive many replies and eventually nothing was done.
Lately the same issue came up on #python-dev and Larry and Nick
su
On Sat, Jan 25, 2014 at 3:07 PM, Larry Hastings wrote:
> 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.
Vote for A. As far a
1) New policy for what can and cannot be converted during the Derby
First, let me apologize for only figuring this out now. The Derby has
been a learning process, discovering things that Argument Clinic didn't
handle. And there were a lot of funny edge cases that we weren't going
to discov
Larry Hastings wrote:
inspect.signature gets this right:
>>> import inspect
>>> str(inspect.signature(c.foo))
'(a)'
Not always.
: Python 3.4.0b2+ (default:32f9e0ae23f7, Jan 18 2014, 13:56:31)
: [GCC 4.2.1 Compatible Apple LLVM 4.2 (clang-425.0.28)] on darwin
: Type "help", "copy
Nick Coghlan, 25.01.2014 10:20:
> On 25 January 2014 17:44, Nick Coghlan wrote:
>> On 25 January 2014 01:07, Larry Hastings wrote:
>>> c) Functions that accept an 'int' when they mean 'boolean' (aka the
>>>"ints instead of bools" problem)
>>>
>>>Solution:
>>> 1) Use "bool".
>>> 2)
On 25 January 2014 19:20, Nick Coghlan wrote:
> On 25 January 2014 17:44, Nick Coghlan wrote:
>> On 25 January 2014 01:07, Larry Hastings wrote:
>>> c) Functions that accept an 'int' when they mean 'boolean' (aka the
>>>"ints instead of bools" problem)
>>>
>>>Solution:
>>> 1) Use "b
On 25 January 2014 17:44, Nick Coghlan wrote:
> On 25 January 2014 01:07, Larry Hastings wrote:
>> 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
35 matches
Mail list logo
