Am 23.11.2010 07:49, schrieb Terry Reedy:
On 11/23/2010 1:16 AM, Senthil Kumaran wrote:
Hi Terry,
On Tue, Nov 23, 2010 at 2:07 PM, terry.reedypython-check...@python.org
wrote:
Author: terry.reedy
Date: Tue Nov 23 07:07:04 2010
New Revision: 86703
Log:
Issue 9222 Fix filetypes for
On 14-Nov-10 3:48 AM, David Bolen wrote:
This is a completely separate issue, though probably around just as
long, and like the popup problem its frequency changes over time. By
hung here I'm referring to cases where something must go wrong with
a test and/or its cleanup such that a python_d
On 11/22/2010 8:33 AM, Guido van Rossum wrote:
On Sun, Nov 21, 2010 at 9:40 PM, Glenn Lindermanv+pyt...@g.nevcal.com wrote:
In reviewing my notes from my experimentations with CGIHTTPServer
(Python2.6) and then http.server (Python 3.2a4), I note one behavior I
haven't reported as a bug,
Hi,
2010/11/23 Glenn Linderman v+pyt...@g.nevcal.com:
File C:\Python32\lib\random.py, line 108, in seed
a = int.from_bytes(_urandom(32), 'big')
WindowsError: [Error -2146893818] Invalid Signature
In the subprocess documentation http://docs.python.org/library/subprocess.html
On Windows,
Am 23.11.2010 11:55, schrieb Amaury Forgeot d'Arc:
Hi,
2010/11/23 Glenn Linderman v+pyt...@g.nevcal.com:
File C:\Python32\lib\random.py, line 108, in seed
a = int.from_bytes(_urandom(32), 'big')
WindowsError: [Error -2146893818] Invalid Signature
In the subprocess documentation
Terry Reedy writes:
Yes. As I read the standard, UCS-2 is limited to BMP chars.
Et tu, Terry?
OK, I change my vote on the suggestion of UCS2 to -1. If a couple
of conscientious blokes like you and David both understand it that
way, I can't see any way to fight it.
FWIW, ISO/IEC 10646 (which
2010/11/23 Łukasz Langa luk...@langa.pl:
If you agree to do that for regrtest I will clean up the tests for warnings.
Already did that for zipfile so it doesn't raise ResourceWarnings anymore. I
just need to correct multiprocessing and xmlrpc ResourceWarnings, silence
some DeprecationWarnings
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 23/11/10 07:55, Martin v. Löwis wrote:
But if we say the Python can be compiled as 64 bits under Solaris,
would
be nice if that was actually true. Now that we have a buildbot (under
OpenIndiana) to test, it is doable.
But it is true, and
On Tue, Nov 23, 2010 at 2:46 AM, exar...@twistedmatrix.com wrote:
On 04:24 pm, solip...@pitrou.net wrote:
On Mon, 22 Nov 2010 17:08:36 +0100
Hrvoje Niksic hrvoje.nik...@avl.com wrote:
On 11/22/2010 04:37 PM, Antoine Pitrou wrote:
+1. The problem with int constants is that the int gets
On 23/11/2010 13:41, Nick Coghlan wrote:
On Tue, Nov 23, 2010 at 2:46 AM,exar...@twistedmatrix.com wrote:
On 04:24 pm, solip...@pitrou.net wrote:
On Mon, 22 Nov 2010 17:08:36 +0100
Hrvoje Niksichrvoje.nik...@avl.com wrote:
On 11/22/2010 04:37 PM, Antoine Pitrou wrote:
+1. The problem with
On Tue, 23 Nov 2010 00:07:09 -0500
Glyph Lefkowitz gl...@twistedmatrix.com wrote:
On Mon, Nov 22, 2010 at 11:13 PM, Hirokazu Yamamoto
ocean-c...@m2.ccsnet.ne.jp wrote:
Hello. Does this affect python? Thank you.
http://www.openssl.org/news/secadv_20101116.txt
No.
Well, actually it
On Tue, Nov 23, 2010 at 8:01 AM, Michael Foord
fuzzy...@voidspace.org.uk wrote:
On 22/11/2010 21:08, Guido van Rossum wrote:
On Mon, Nov 22, 2010 at 11:24 AM, Brett Cannonbr...@python.org wrote:
The problem with that is it means developers who switch to Python 3.2
or whatever are suddenly
On Mon, 22 Nov 2010 22:00:08 -0600
Benjamin Peterson benja...@python.org wrote:
2010/11/22 Łukasz Langa luk...@langa.pl:
Wiadomość napisana przez Benjamin Peterson w dniu 2010-11-23, o godz. 00:47:
No test?
The tests were there already, raising ResourceWarnings. After this change,
On Tue, Nov 23, 2010 at 11:50 PM, Michael Foord
fuzzy...@voidspace.org.uk wrote:
PEP 354 was rejected for two primary reasons - lack of interest and nowhere
obvious to put it. Would it be *so bad* if an enum type lived in its own
module? There is certainly more interest now, and if we are to
On 23/11/2010 14:16, Nick Coghlan wrote:
On Tue, Nov 23, 2010 at 11:50 PM, Michael Foord
fuzzy...@voidspace.org.uk wrote:
PEP 354 was rejected for two primary reasons - lack of interest and nowhere
obvious to put it. Would it be *so bad* if an enum type lived in its own
module? There is
On Tue, 23 Nov 2010 14:24:18 +
Michael Foord fuzzy...@voidspace.org.uk wrote:
Well, for backwards compatibility reasons the new constants would have
to *behave* like the old ones (including having the same underlying
value and comparing equal to it).
In many cases it is *likely* that
2010/11/23 Antoine Pitrou solip...@pitrou.net:
On Mon, 22 Nov 2010 22:00:08 -0600
Benjamin Peterson benja...@python.org wrote:
2010/11/22 Łukasz Langa luk...@langa.pl:
Wiadomość napisana przez Benjamin Peterson w dniu 2010-11-23, o godz.
00:47:
No test?
The tests were there
2010/11/23 Antoine Pitrou solip...@pitrou.net:
On Tue, 23 Nov 2010 14:24:18 +
Michael Foord fuzzy...@voidspace.org.uk wrote:
Well, for backwards compatibility reasons the new constants would have
to *behave* like the old ones (including having the same underlying
value and comparing equal
On 23/11/2010 14:42, Antoine Pitrou wrote:
On Tue, 23 Nov 2010 14:24:18 +
Michael Foordfuzzy...@voidspace.org.uk wrote:
Well, for backwards compatibility reasons the new constants would have
to *behave* like the old ones (including having the same underlying
value and comparing equal to
If you don't care about the ISO standard, but only about Python,
Martin's right, I was wrong. You can stop reading now.wink
Martin v. Löwis writes:
I could only find the FCD of 10646:2010, where annex H was integrated
into section 10:
Thank you for the reference.
I referred to two older
Le mardi 23 novembre 2010 à 08:52 -0600, Benjamin Peterson a écrit :
2010/11/23 Antoine Pitrou solip...@pitrou.net:
On Tue, 23 Nov 2010 14:24:18 +
Michael Foord fuzzy...@voidspace.org.uk wrote:
Well, for backwards compatibility reasons the new constants would have
to *behave* like the
Le mardi 23 novembre 2010 à 14:56 +, Michael Foord a écrit :
On 23/11/2010 14:42, Antoine Pitrou wrote:
On Tue, 23 Nov 2010 14:24:18 +
Michael Foordfuzzy...@voidspace.org.uk wrote:
Well, for backwards compatibility reasons the new constants would have
to *behave* like the old
Le mardi 23 novembre 2010 à 08:49 -0600, Benjamin Peterson a écrit :
2010/11/23 Antoine Pitrou solip...@pitrou.net:
On Mon, 22 Nov 2010 22:00:08 -0600
Benjamin Peterson benja...@python.org wrote:
2010/11/22 Łukasz Langa luk...@langa.pl:
Wiadomość napisana przez Benjamin Peterson w dniu
On 23/11/2010 15:01, Antoine Pitrou wrote:
Le mardi 23 novembre 2010 à 08:52 -0600, Benjamin Peterson a écrit :
2010/11/23 Antoine Pitrousolip...@pitrou.net:
On Tue, 23 Nov 2010 14:24:18 +
Michael Foordfuzzy...@voidspace.org.uk wrote:
Well, for backwards compatibility reasons the new
Le mardi 23 novembre 2010 à 15:15 +, Michael Foord a écrit :
There are still two reasonable APIs (unless you have changed your mind
and think that sticking with plain integers is best), of which I prefer
the latter:
SOME_CONST = Constant('SOME_CONST', 1)
OTHER_CONST =
On 23/11/2010 15:30, Antoine Pitrou wrote:
Le mardi 23 novembre 2010 à 15:15 +, Michael Foord a écrit :
There are still two reasonable APIs (unless you have changed your mind
and think that sticking with plain integers is best), of which I prefer
the latter:
SOME_CONST =
Le mardi 23 novembre 2010 à 15:40 +, Michael Foord a écrit :
On 23/11/2010 15:30, Antoine Pitrou wrote:
Le mardi 23 novembre 2010 à 15:15 +, Michael Foord a écrit :
There are still two reasonable APIs (unless you have changed your mind
and think that sticking with plain integers is
On 23/11/2010 16:05, Antoine Pitrou wrote:
Le mardi 23 novembre 2010 à 15:40 +, Michael Foord a écrit :
On 23/11/2010 15:30, Antoine Pitrou wrote:
Le mardi 23 novembre 2010 à 15:15 +, Michael Foord a écrit :
There are still two reasonable APIs (unless you have changed your mind
and
On Tue, 23 Nov 2010 15:15:29 +, Michael Foord wrote:
There are still two reasonable APIs (unless you have changed your mind
and think that sticking with plain integers is best), of which I prefer
the latter:
SOME_CONST = Constant('SOME_CONST', 1)
OTHER_CONST = Constant('OTHER_CONST',
Martin v. Löwis writes:
I disagree: Quoting from Unicode 5.0, section 5.4:
# The individual components of implementations may have different
# levels of support for surrogates, as long as those components are
# assembled and communicate correctly.
Assembly is the problem. If chr() or
Nick Coghlan writes:
For practical purposes, UCS2/UCS4 convey far more inherent information
than narrow/wide:
That was my stance, but in fact (1) the ISO JTC1/SC2 has deliberately
made them ambiguous by changing their definitions over the years[1],
and (2) the more recent definitions and
On 23/11/2010 15:37, ben.cottr...@nominum.com wrote:
On Tue, 23 Nov 2010 15:15:29 +, Michael Foord wrote:
There are still two reasonable APIs (unless you have changed your mind
and think that sticking with plain integers is best), of which I prefer
the latter:
SOME_CONST =
On Nov 23, 2010, at 01:50 PM, Michael Foord wrote:
Right. As it happens I just submitted a patch to Barry Warsaw's enum package
(nice), flufl.enum [1], to allow namedtuple style creation of named
constants:
Thanks for the plug (and the nice patch).
FWIW, the documentation for the package is
On Nov 23, 2010, at 03:15 PM, Michael Foord wrote:
(Well, there is a third option that takes __name__ and sets the constants in
the module automagically. I can understand why people would dislike that
though.)
Personally, I think if you want that, then the explicit class definition is a
better
At 11:31 AM 11/23/2010 -0500, Barry Warsaw wrote:
On Nov 23, 2010, at 03:15 PM, Michael Foord wrote:
(Well, there is a third option that takes __name__ and sets the constants in
the module automagically. I can understand why people would dislike that
though.)
Personally, I think if you want
On 23/11/2010 16:27, Barry Warsaw wrote:
On Nov 23, 2010, at 01:50 PM, Michael Foord wrote:
Right. As it happens I just submitted a patch to Barry Warsaw's enum package
(nice), flufl.enum [1], to allow namedtuple style creation of named
constants:
Thanks for the plug (and the nice patch).
Le mardi 23 novembre 2010 à 12:32 -0500, Isaac Morland a écrit :
On Tue, 23 Nov 2010, Antoine Pitrou wrote:
We already have a bunch of bizarrely unrelated stuff in collections
(such as Callable), so we could put enum there too.
Why not just enum (i.e., from enum import [...] or import
On Tue, 23 Nov 2010, Antoine Pitrou wrote:
We already have a bunch of bizarrely unrelated stuff in collections
(such as Callable), so we could put enum there too.
Why not just enum (i.e., from enum import [...] or import
enum.[...])? Enumerations are one of the basic kinds of types overall
On Tue, 23 Nov 2010, Antoine Pitrou wrote:
Le mardi 23 novembre 2010 à 12:32 -0500, Isaac Morland a écrit :
On Tue, 23 Nov 2010, Antoine Pitrou wrote:
We already have a bunch of bizarrely unrelated stuff in collections
(such as Callable), so we could put enum there too.
Why not just enum
On Tue, Nov 23, 2010 at 12:37 PM, Antoine Pitrou solip...@pitrou.net wrote:
Enumerations aren't a type at all (they have no distinguishing
property).
In any given language, this may be true, or not. Whether they should
be distinct in Python is core to the current discussion.
From a
Le mardi 23 novembre 2010 à 12:57 -0500, Fred Drake a écrit :
On Tue, Nov 23, 2010 at 12:37 PM, Antoine Pitrou solip...@pitrou.net wrote:
Enumerations aren't a type at all (they have no distinguishing
property).
In any given language, this may be true, or not. Whether they should
be
Le mardi 23 novembre 2010 à 12:50 -0500, Isaac Morland a écrit :
Each enumeration is a type (well, OK, not in every language, presumably,
but certainly in many languages). The word basic is more important than
types in my sentence - the point is that an enumeration capability is a
very
On 11/23/2010 3:55 AM, Martin v. Löwis wrote:
Am 23.11.2010 11:55, schrieb Amaury Forgeot d'Arc:
Hi,
2010/11/23 Glenn Lindermanv+pyt...@g.nevcal.com:
File C:\Python32\lib\random.py, line 108, in seed
a = int.from_bytes(_urandom(32), 'big')
WindowsError: [Error -2146893818] Invalid
On 11/22/2010 2:56 PM, Tim Lesher wrote:
On Mon, Nov 22, 2010 at 16:54, Glenn Lindermanv+pyt...@g.nevcal.com wrote:
I suppose it is possible that some environment variables are used by Python
directly (but I can't seem to find a documented list of them) although I
would expect that usage to be
On Mon, Nov 22, 2010 at 1:13 PM, Raymond Hettinger
raymond.hettin...@gmail.com wrote:
..
Any explanation we give users needs to let them know two things:
* that we cover the entire range of unicode not just BMP
* that sometimes len(chr(i)) is one and sometimes two
This discussion motivated me
2010/11/23 Alexander Belopolsky alexander.belopol...@gmail.com:
This discussion motivated me to start looking into how well Python
library itself is prepared to deal with len(chr(i)) = 2. I was not
surprised to find that textwrap does not handle the issue that well:
len(wrap(' \U00010140' *
Isaac Morland ijmor...@uwaterloo.ca wrote:
On Tue, 23 Nov 2010, Antoine Pitrou wrote:
Le mardi 23 novembre 2010 à 12:32 -0500, Isaac Morland a écrit :
On Tue, 23 Nov 2010, Antoine Pitrou wrote:
We already have a bunch of bizarrely unrelated stuff in collections
(such as Callable), so
Alexander Belopolsky wrote:
On Mon, Nov 22, 2010 at 1:13 PM, Raymond Hettinger
raymond.hettin...@gmail.com wrote:
..
Any explanation we give users needs to let them know two things:
* that we cover the entire range of unicode not just BMP
* that sometimes len(chr(i)) is one and sometimes two
On Tue, Nov 23, 2010 at 10:06 AM, Antoine Pitrou solip...@pitrou.net wrote:
Le mardi 23 novembre 2010 à 12:57 -0500, Fred Drake a écrit :
On Tue, Nov 23, 2010 at 12:37 PM, Antoine Pitrou solip...@pitrou.net wrote:
Enumerations aren't a type at all (they have no distinguishing
property).
In
On Nov 23, 2010, at 12:57 PM, Fred Drake wrote:
From a backward-compatibility perspective, what makes sense depends on
whether they're used to implement existing constants (socket.AF_INET,
etc.) or if they reserved for new features only.
As is usually the case, there's little reason to change
On Nov 23, 2010, at 05:02 PM, Michael Foord wrote:
* Enums are not subclassed from ints or strs. They are a distinct data type
that can be converted to and from ints and strs. EIBTI.
But if we are to use it *in* the standard library (as opposed to merely
adding a module *to* the standard
On Nov 23, 2010, at 11:52 AM, P.J. Eby wrote:
This reminds me: a stdlib enum should support proper pickling and copying;
i.e.:
assert SomeEnum.anEnum is pickle.loads(pickle.dumps(SomeEnum.anEnum))
This could probably be implemented by adding something like:
def __reduce__(self):
On Tue, Nov 23, 2010 at 11:47 AM, Barry Warsaw ba...@python.org wrote:
On Nov 23, 2010, at 05:02 PM, Michael Foord wrote:
* Enums are not subclassed from ints or strs. They are a distinct data type
that can be converted to and from ints and strs. EIBTI.
But if we are to use it *in* the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Happen to me last Sunday, and happening just now.
I can access http://bugs.python.org/ just fine, but trying to post a
message, open a new bug, change nosy, etc., takes a LONG time (minutes)
and it is finally failing with a 400 Bad Request error:
I have read some about side-by-side assemblies but had considered them a
good reason to stick with the outdated M$VC 6.0 compiler, which doesn't
seem to need to create them, and their myriad requirements, which seem
far from necessary for simply compiling a program. I was disappointed
to
On 11/23/2010 12:33 PM, Martin v. Löwis wrote:
In any case, VS 2010 will stop using SxS for the CRT.
Good news! Maybe M$VC will become a useful compiler yet again :)
___
Python-Dev mailing list
Python-Dev@python.org
On 11/23/2010 11:34 AM, Guido van Rossum wrote:
The best example of the utility of enums even for Python is bool. I
resisted this for the longest time but people kept asking for it. Some
properties of bool:
(a) bool is a (final) subclass of int, and an int is acceptable in a
pinch where a bool
Le mardi 23 novembre 2010 à 11:34 -0800, Guido van Rossum a écrit :
From a backward-compatibility perspective, what makes sense depends on
whether they're used to implement existing constants (socket.AF_INET,
etc.) or if they reserved for new features only.
It's not only backwards
On 11/23/2010 12:07 PM, Antoine Pitrou wrote:
Le mardi 23 novembre 2010 à 12:50 -0500, Isaac Morland a écrit :
Each enumeration is a type (well, OK, not in every language, presumably,
but certainly in many languages). The word basic is more important than
types in my sentence - the point is
On Nov 23, 2010, at 10:37 AM, ben.cottr...@nominum.com wrote:
I'd prefer not to think of the number of times I've made the following
mistake:
s = socket.socket(socket.SOCK_DGRAM, socket.AF_INET)
If it's any consolation, it's fewer than the number of times I have :).
(More fun, actually,
Antoine Pitrou wrote:
Constants = make_constants('Constants', 'SOME_CONST OTHER_CONST',
values=range(1, 3))
Again, auto-enumeration is useless since it's trivial to achieve
explicitly.
That doesn't make auto-enumeration useless. Unnecessary, perhaps, but
not
On Nov 23, 2010, at 10:01 AM, Antoine Pitrou wrote:
Well, it is easy to assign range(N) to a tuple of names when desired. I
don't think an automatically-enumerating constant generator is needed.
I don't think that numerical enumerations are the only kind of constants we're
talking about.
Le mardi 23 novembre 2010 à 16:10 -0500, Glyph Lefkowitz a écrit :
On Nov 23, 2010, at 10:01 AM, Antoine Pitrou wrote:
Well, it is easy to assign range(N) to a tuple of names when
desired. I
don't think an automatically-enumerating constant generator is
needed.
I don't think that
Oops.. x**2 should have been 2**x below.
On 11/23/2010 03:03 PM, Ron Adam wrote:
On 11/23/2010 12:07 PM, Antoine Pitrou wrote:
Le mardi 23 novembre 2010 à 12:50 -0500, Isaac Morland a écrit :
Each enumeration is a type (well, OK, not in every language, presumably,
but certainly in many
Antoine Pitrou wrote:
Python already has an enumeration capability. It's called range().
There's nothing else that C enums have. AFAICT, neither do enums in
other mainstream languages (assuming they even exist; I don't remember
Perl, PHP or Javascript having anything like that, but perhaps I'm
Antoine Pitrou wrote:
I don't understand why people insist on calling that an enum. enum is
a C legacy and it doesn't bring anything useful as I can tell.
The usefulness is that they can have a str() or repr() that
displays the name of the value instead of an integer.
The bool type was added
Antoine Pitrou wrote:
Well, it's been inherited by C-like languages, no doubt. Like braces and
semicolumns :)
The idea isn't confined to the C family. Pascal and many of the
languages inspired by it also have enumerated types.
--
Greg
___
On 11/23/2010 2:11 PM, Alexander Belopolsky wrote:
This discussion motivated me to start looking into how well Python
library itself is prepared to deal with len(chr(i)) = 2. I was not
Good idea!
surprised to find that textwrap does not handle the issue that well:
len(wrap(' \U00010140'
On 11/23/2010 5:43 PM, Éric Araujo wrote:
Modified: python/branches/py3k/Misc/ACKS
==
--- python/branches/py3k/Misc/ACKS (original)
+++ python/branches/py3k/Misc/ACKS Tue Nov 23 21:32:47 2010
@@ -1,4 +1,4 @@
On Tue, 23 Nov 2010, Bill Janssen wrote:
The main purpose of that is to be able to catch type mismatches with
static typing, though. Seems kind of pointless for Python.
The concept can work dynamically. In fact, the flufl.enum package which
has been discussed here makes each enumeration
Trent Nelson tr...@snakebite.org writes:
That's interesting. (That kill_python.exe doesn't kill the wedged
processes, but pskill does.) kill_python is pretty simple, it just
calls TerminateProcess() after acquiring a handle with the relevant
PROCESS_TERMINATE access right. (...)
Are you
Antoine Pitrou wrote:
I think that asking for too many features would get in the way, and also
make the API quite un-Pythonic. If you want your values to be e.g.
OR'able, just choose your values wisely ;)
On the other hand it could be useful to have an easy way to
request power-of-2 value
Bill Janssen wrote:
The main purpose of that is to be able to catch type mismatches with
static typing, though. Seems kind of pointless for Python.
But catching type mismatches with dynamic typing doesn't
seem pointless for Python. There's nothing static about
the proposals being made here
Antoine Pitrou wrote:
Constants = make_constants('Constants', 'SOME_CONST OTHER_CONST',
values=range(1, 3))
Again, auto-enumeration is useless since it's trivial to achieve
explicitly.
But seeing as it's going to be a common thing to do, why not
make it the
Isaac Morland wrote:
In any case my
suggestion of a new keyword was not meant to be taken seriously.
I don't think it need be taken entirely as a joke, either.
All the proposed patterns for creating enums that I've seen
end up leaving something to be desired. They violate DRY
by requiring you
Alexander Belopolsky wrote:
Because the most commonly used characters are all in the Basic
Multilingual Plane, converting between surrogate pairs and the
original values is often not tested thoroughly. This leads to
persistent bugs, and potential security holes, even in popular and
On Nov 23, 2010, at 6:49 PM, Greg Ewing wrote:
Maybe Python should have used UTF-8 as its internal unicode
representation. Then people who were foolish enough to assume
one character per string item would have their programs break
rather soon under only light unicode testing. :-)
You put a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 23/11/10 21:33, Jesus Cea wrote:
Happen to me last Sunday, and happening just now.
I can access http://bugs.python.org/ just fine, but trying to post a
message, open a new bug, change nosy, etc., takes a LONG time (minutes)
and it is finally
On 23/11/2010 21:15, Antoine Pitrou wrote:
Le mardi 23 novembre 2010 à 16:10 -0500, Glyph Lefkowitz a écrit :
On Nov 23, 2010, at 10:01 AM, Antoine Pitrou wrote:
Well, it is easy to assign range(N) to a tuple of names when
desired. I
don't think an automatically-enumerating constant generator
Hi there!
py3k built from trunk on Centos 5.5 freezes during regrtest on
test_concurrent_futures with Fatal Python error: Invalid thread state for this
thread. As in a typical concurrent problem, subsequent calls freeze in
different test cases, but the freeze itself is always reproducible and
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 24/11/10 01:31, Jesus Cea wrote:
Still retrying, with no luck.
Anybody else can reproduce?.
One of my tracker changes was just processed.
The important one still retrying every 5 minutes...
I hope I can go sleep before dawn :-P.
- --
Jesus
On 11/23/2010 8:32 PM, Jesus Cea wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 24/11/10 01:31, Jesus Cea wrote:
Still retrying, with no luck.
Anybody else can reproduce?.
One of my tracker changes was just processed.
The important one still retrying every 5 minutes...
I hope I
On Nov 23, 2010, at 7:22 PM, James Y Knight wrote:
On Nov 23, 2010, at 6:49 PM, Greg Ewing wrote:
Maybe Python should have used UTF-8 as its internal unicode
representation. Then people who were foolish enough to assume
one character per string item would have their programs break
rather
On Nov 23, 2010, at 9:02 AM, Antoine Pitrou wrote:
On Tue, 23 Nov 2010 00:07:09 -0500
Glyph Lefkowitz gl...@twistedmatrix.com wrote:
On Mon, Nov 22, 2010 at 11:13 PM, Hirokazu Yamamoto
ocean-c...@m2.ccsnet.ne.jp wrote:
Hello. Does this affect python? Thank you.
Alexander Belopolsky writes:
Yet finding a bug in a str object method after a 5 min review was a
bit discouraging:
'xyz'.center(20, '\U00010140')
Traceback (most recent call last):
File stdin, line 1, in module
TypeError: The fill character must be exactly one character long
On Nov 23, 2010, at 3:41 PM, Greg Ewing wrote:
While it may be possible to work around these things with
sufficient levels of metaclass hackery and black magic, at
some point one has to consider whether new syntax might
be the least worst option.
The least worst option is to do nothing at
James Y Knight writes:
You put a smiley, but, in all seriousness, I think that's actually
the right thing to do if anyone writes a new programming
language. It is clearly the right thing if you don't have to be
concerned with backwards-compatibility: nobody really needs to be
able to
On Tue, Nov 23, 2010 at 9:35 PM, Raymond Hettinger
raymond.hettin...@gmail.com wrote:
The least worst option is to do nothing at all.
For the standard library, I agree.
There are enough variants that are needed/desired in different
contexts, and there isn't a single clear winner. Nor is there
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 24/11/10 02:51, Terry Reedy wrote:
I hope I can go sleep before dawn :-P.
I added a comment to one issue and opened another with no problem during
the last couple of hours.
My changes have work now. After like 8 hours and a retry every five
On Nov 23, 2010, at 9:44 PM, Stephen J. Turnbull wrote:
James Y Knight writes:
You put a smiley, but, in all seriousness, I think that's actually
the right thing to do if anyone writes a new programming
language. It is clearly the right thing if you don't have to be
concerned with
Where might I find the bug #427345 that is referred to in a comment
inside http.server ? Here is a code excerpt:
# throw away additional data [see bug #427345]
while select.select([self.rfile._sock], [], [], 0)[0]:
if not self.rfile._sock.recv(1):
On Tue, Nov 23, 2010 at 22:28, Glenn Linderman
v+pyt...@g.nevcal.comv%2bpyt...@g.nevcal.com
wrote:
Where might I find the bug #427345 that is referred to in a comment inside
http.server ? Here is a code excerpt:
# throw away additional data [see bug #427345]
while
Note that I'm not saying that there shouldn't be a UTF-8 string type;
I'm just saying that for some purposes it might be a good idea to keep
UTF-16 and UTF-32 string types around.
Glyph Lefkowitz writes:
The theory is that accessing the first character of a region in a
string often occurs
On Nov 24, 2010, at 12:07 AM, Stephen J. Turnbull wrote:
Or you can give user programs memory indicies, and enjoy the fun as
the poor developers do things like pos += 1 which works fine on
the ASCII data they have lying around, then wonder why they get
Unicode errors when they take substrings.
On Nov 24, 2010, at 12:07 AM, Stephen J. Turnbull wrote:
By the way, to send the ball back into your court, I have this feeling
that the demand for UTF-8 is once again driven by native English
speakers who are very shortly going to find themselves, and the data
they are most familiar with,
On 11/21/2010 8:39 PM, R. David Murray wrote:
On Sun, 21 Nov 2010 19:59:54 -0800, Glenn Lindermanv+pyt...@g.nevcal.com
wrote:
On 11/21/2010 9:18 AM, R. David Murray wrote:
I want to look at the CGI issue, but I'm not sure when I'll get to it.
Actually, since this code was working before
96 matches
Mail list logo
