On 17 March 2012 00:57, Guido van Rossum gu...@python.org 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
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
On 17 March 2012 05:28, Mark Hammond skippy.hamm...@gmail.com 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
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
On 17 March 2012 10:43, Stefan Behnel stefan...@behnel.de 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
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 ElementTree
On 17 March 2012 14:07, Serhiy Storchaka storch...@gmail.com 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
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 stefan...@behnel.de wrote:
Merlijn van Deen, 17.03.2012 15:20:
On 17 March 2012 10:43, Stefan Behnel wrote:
In lxml, there was an
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
On 03/15/2012 01:17 AM, victor.stinner wrote:
http://hg.python.org/cpython/rev/27441e0d6a75
changeset: 75672:27441e0d6a75
user:Victor Stinner victor.stin...@gmail.com
date:Thu Mar 15 01:17:09 2012 +0100
summary:
Issue #10278: Add an optional strict argument to
On 17 March 2012 16:28, Serhiy Storchaka storch...@gmail.com 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 sent...@uthcode.com
date:Sat Mar 17 00:40:34 2012 -0700
summary:
3.2 explain
Hi,
changeset: 509b222679e8
branch: 3.2
user:Benjamin Peterson benja...@python.org
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
On 03/17/2012 06:20 PM, Éric Araujo wrote:
Hi,
changeset: 509b222679e8
branch: 3.2
user:Benjamin Peterson benja...@python.org
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
---
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
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 victor.stin...@gmail.com
date:Thu Mar 15 01:17:09 2012 +0100
summary:
Issue
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
victor.stin...@gmail.com date:Thu Mar 15
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 monotonic clock
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:Victor Stinner
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 ba...@python.org
date:Sat Mar 17 18:34:05 2012 -0400
summary:
Added tag v2.6.8rc2
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
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
22 matches
Mail list logo
