On 17 March 2012 00:57, Guido van Rossum wrote:
> OK, how about using encoding=bytes (yes, the type object!)? Or 'bytes' ?
encoding=bytes makes (at least intuitive) sense to me;
encoding='bytes' would imply there is an encoding with name 'bytes'
that somehow does b''.decode('bytes')=b'', and woul
Guido van Rossum, 17.03.2012 00:57:
> OK, how about using encoding=bytes (yes, the type object!)? Or 'bytes' ?
In lxml, there was an "encoding=unicode" option that would let the
XML/HTML/text serialisation function return a Unicode string. This was
eventually deprecated in favour of "encoding='uni
On 17 March 2012 05:28, Mark Hammond wrote:
>> I hate to seem like I'm piling on now after panning your last brainstorm
>> :-), but... this would be quite problematic for virtualenv users, many
>> of whom do rely on the fact that the virtualenv "stuff" is confined to
>> within a limited set of kn
17.03.12 13:57, Paul Moore написав(ла):
As there is no
way of knowing the Python version without running Python, this is too
slow to be practical.
Cold start:
$ time python3 --version
Python 3.1.2
real0m0.073s
user0m0.004s
sys 0m0.004s
Hot start:
$ time python3 --version
Python 3.
On 17 March 2012 10:43, Stefan Behnel wrote:
> In lxml, there was an "encoding=unicode" option that would let the
> XML/HTML/text serialisation function return a Unicode string. This was
> eventually deprecated in favour of "encoding='unicode'" when ElementTree
> gained this feature as well some y
Merlijn van Deen, 17.03.2012 15:20:
> On 17 March 2012 10:43, Stefan Behnel wrote:
>> In lxml, there was an "encoding=unicode" option that would let the
>> XML/HTML/text serialisation function return a Unicode string. This was
>> eventually deprecated in favour of "encoding='unicode'" when ElementT
On 17 March 2012 14:07, Serhiy Storchaka wrote:
> 17.03.12 13:57, Paul Moore написав(ла):
>
>> As there is no
>> way of knowing the Python version without running Python, this is too
>> slow to be practical.
>
>
> Cold start:
> $ time python3 --version
> Python 3.1.2
>
> real 0m0.073s
> user
One reason to use 'bytes' instead of bytes is that it is a string that
can be specified e.g. in a config file.
On Sat, Mar 17, 2012 at 7:28 AM, Stefan Behnel wrote:
> Merlijn van Deen, 17.03.2012 15:20:
>> On 17 March 2012 10:43, Stefan Behnel wrote:
>>> In lxml, there was an "encoding=unicode" o
17.03.12 17:00, Guido van Rossum написав(ла):
One reason to use 'bytes' instead of bytes is that it is a string that
can be specified e.g. in a config file.
Thus, there are no reasons to use bytes instead of 'bytes'.
___
Python-Dev mailing list
Pytho
On 03/15/2012 01:17 AM, victor.stinner wrote:
> http://hg.python.org/cpython/rev/27441e0d6a75
> changeset: 75672:27441e0d6a75
> user:Victor Stinner
> date:Thu Mar 15 01:17:09 2012 +0100
> summary:
> Issue #10278: Add an optional strict argument to time.steady(), False by
> def
On 17 March 2012 16:28, Serhiy Storchaka wrote:
> Thus, there are no reasons to use bytes instead of 'bytes'.
Aesthetics ;-)
I've implemented the encoding="bytes" version [1]. Thank you all for your input!
Merlijn
[1] http://bugs.python.org/issue6784#msg156166
__
On 03/17/2012 08:41 AM, senthil.kumaran wrote:
> http://hg.python.org/cpython/rev/613919591a05
> changeset: 75778:613919591a05
> branch: 3.2
> parent: 75771:32d3ecacdabf
> user:Senthil Kumaran
> date:Sat Mar 17 00:40:34 2012 -0700
> summary:
> 3.2 explain json.dumps f
Hi,
> changeset: 509b222679e8
> branch: 3.2
> user:Benjamin Peterson
> date:Wed Mar 07 18:49:43 2012 -0600
> summary:
> this stuff will actually be new in 3.2.4
> diff --git a/Misc/NEWS b/Misc/NEWS
> --- a/Misc/NEWS
> +++ b/Misc/NEWS
> @@ -2,6 +2,57 @@
> Python News
>
On 03/17/2012 06:20 PM, Éric Araujo wrote:
> Hi,
>
>> changeset: 509b222679e8
>> branch: 3.2
>> user:Benjamin Peterson
>> date:Wed Mar 07 18:49:43 2012 -0600
>> summary:
>> this stuff will actually be new in 3.2.4
>
>> diff --git a/Misc/NEWS b/Misc/NEWS
>> --- a/Misc/NEW
On 3/17/2012 10:50 AM, Paul Moore wrote:
Meh. None of this is a real issue. It's just some extra messy coding.
But Van's point is that this proposal gives him less hard coding.
Beyond pointing out that it gives me more, I don't have much to add.
I suspect a case could be made that harmonizatio
On 17 Mar 2012, at 08:49, Georg Brandl wrote:
> On 03/15/2012 01:17 AM, victor.stinner wrote:
>> http://hg.python.org/cpython/rev/27441e0d6a75
>> changeset: 75672:27441e0d6a75
>> user:Victor Stinner
>> date:Thu Mar 15 01:17:09 2012 +0100
>> summary:
>> Issue #10278: Add an opt
On 03/17/2012 09:47 PM, Michael Foord wrote:
>
> On 17 Mar 2012, at 08:49, Georg Brandl wrote:
>
>> On 03/15/2012 01:17 AM, victor.stinner wrote:
>>> http://hg.python.org/cpython/rev/27441e0d6a75 changeset:
>>> 75672:27441e0d6a75 user:Victor Stinner
>>> date:Thu Mar 15 01:17:09 2
On 3/17/2012 4:47 PM, Michael Foord wrote:
>
> On 17 Mar 2012, at 08:49, Georg Brandl wrote:
>
>> On 03/15/2012 01:17 AM, victor.stinner wrote:
>>> + If available, a monotonic clock is used. By default, if *strict* is
>>> False,
>>> + the function falls back to another clock if the monotoni
On 17 Mar 2012, at 15:04, Georg Brandl wrote:
> On 03/17/2012 09:47 PM, Michael Foord wrote:
>>
>> On 17 Mar 2012, at 08:49, Georg Brandl wrote:
>>
>>> On 03/15/2012 01:17 AM, victor.stinner wrote:
http://hg.python.org/cpython/rev/27441e0d6a75 changeset:
75672:27441e0d6a75 user:
On Mar 17, 2012, at 11:34 PM, barry.warsaw wrote:
>http://hg.python.org/cpython/rev/6144a0748a95
>changeset: 75809:6144a0748a95
>branch: 2.6
>parent: 75806:bd9e1a02e3e3
>user:Barry Warsaw
>date:Sat Mar 17 18:34:05 2012 -0400
>summary:
> Added tag v2.6.8rc2 for changes
On Mar 18, 2012, at 12:03 AM, Georg Brandl wrote:
>I'm afraid it's the latter: tags are entries in .hgtags. So when you
>completely null-merge your 2.6 changes into 2.7, you are basically removing
>the tag from the 2.7 branch. And since to find tags, Mercurial looks in the
>.hgtags files of all a
On Mar 17, 2012, at 07:15 PM, Éric Araujo wrote:
>Note that duplicate entries in .hgtags (when a tag was redone) should
>not be “cleaned up”: the presence of the old changeset hash greatly
>helps conflict resolution. (If someone pulled the repo with the old tag
>and later pulls and updates, then
On 03/18/2012 12:15 AM, Éric Araujo wrote:
> Hi,
>
> Le 17/03/2012 19:03, Georg Brandl a écrit :
>> On 03/17/2012 11:43 PM, Barry Warsaw wrote:
>> I'm afraid it's the latter: tags are entries in .hgtags. So when you
>> completely
>> null-merge your 2.6 changes into 2.7, you are basically removing
23 matches
Mail list logo
