On 11/21/2010 8:39 PM, R. David Murray wrote:
On Sun, 21 Nov 2010 19:59:54 -0800, Glenn Linderman
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 3.x, and if email.parser
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 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 substr
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 occu
On Tue, Nov 23, 2010 at 22:28, Glenn Linderman
> 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 select.select([self.rfile._sock], [], [
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 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
-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 fi
On Tue, Nov 23, 2010 at 9:35 PM, Raymond Hettinger
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 any
compelling reason to ha
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 t
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 a
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 "", line 1, in
> TypeError: The fill character must be exactly one character long
>
On Nov 23, 2010, at 9:02 AM, Antoine Pitrou wrote:
> On Tue, 23 Nov 2010 00:07:09 -0500
> Glyph Lefkowitz 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/s
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
>> ra
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 ca
-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.
- --
Jes
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
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
-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 fina
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
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
well-revi
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 t
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 defau
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 th
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 assi
Trent Nelson 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 calling pskill
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 int
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 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' *
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
___
Python-Dev
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 adde
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
m
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 lan
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
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. O
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 u
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, actuall
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
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 back
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 i
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
http://mail.python.org/mailman/l
> 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
-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:
"
On Tue, Nov 23, 2010 at 11:47 AM, Barry Warsaw 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 standa
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 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 sta
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 Tue, Nov 23, 2010 at 10:06 AM, Antoine Pitrou wrote:
> Le mardi 23 novembre 2010 à 12:57 -0500, Fred Drake a écrit :
>> On Tue, Nov 23, 2010 at 12:37 PM, Antoine Pitrou wrote:
>> > Enumerations aren't a type at all (they have no distinguishing
>> > property).
>>
>> In any given language, this
Alexander Belopolsky wrote:
> On Mon, Nov 22, 2010 at 1:13 PM, Raymond Hettinger
> 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 discussi
Isaac Morland 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 we
2010/11/23 Alexander Belopolsky :
> 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' * 80, 20))
> 12
len(
On Mon, Nov 22, 2010 at 1:13 PM, Raymond Hettinger
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 to start looking into how
On 11/22/2010 2:56 PM, Tim Lesher wrote:
On Mon, Nov 22, 2010 at 16:54, Glenn Linderman 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 optional, with fall-b
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 Linderman:
File "C:\Python32\lib\random.py", line 108, in seed
a = int.from_bytes(_urandom(32), 'big')
WindowsError: [Error -2146893818] Invalid Signature
In the sub
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
> v
Le mardi 23 novembre 2010 à 12:57 -0500, Fred Drake a écrit :
> On Tue, Nov 23, 2010 at 12:37 PM, Antoine Pitrou 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 Pyth
On Tue, Nov 23, 2010 at 12:37 PM, Antoine Pitrou 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 backward-compatibility pers
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, 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 ove
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 [...]" o
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).
FWI
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 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
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 h
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 = Constant('SOME_CO
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 "i
"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
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_CON
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 thi
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 inte
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 = Constant('SOME_CONS
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 = Constant('O
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 Pitrou:
On Tue, 23 Nov 2010 14:24:18 +
Michael Foord wrote:
Well, for backwards compatibility reasons the new constants would have
to *behave* like the old on
Le mardi 23 novembre 2010 à 08:49 -0600, Benjamin Peterson a écrit :
> 2010/11/23 Antoine Pitrou :
> > On Mon, 22 Nov 2010 22:00:08 -0600
> > Benjamin Peterson wrote:
> >> 2010/11/22 Łukasz Langa :
> >> > Wiadomość napisana przez Benjamin Peterson w dniu 2010-11-23, o godz.
> >> > 00:47:
> >> >
>
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 Foord wrote:
> >> Well, for backwards compatibility reasons the new constants would have
> >> to *behave* like the old ones (including ha
Le mardi 23 novembre 2010 à 08:52 -0600, Benjamin Peterson a écrit :
> 2010/11/23 Antoine Pitrou :
> > On Tue, 23 Nov 2010 14:24:18 +
> > Michael Foord wrote:
> >> Well, for backwards compatibility reasons the new constants would have
> >> to *behave* like the old ones (including having the sa
If you don't care about the ISO standard, but only about Python,
Martin's right, I was wrong. You can stop reading now.
"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 ve
On 23/11/2010 14:42, Antoine Pitrou wrote:
On Tue, 23 Nov 2010 14:24:18 +
Michael Foord 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 *l
2010/11/23 Antoine Pitrou :
> On Tue, 23 Nov 2010 14:24:18 +
> Michael Foord 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 *l
2010/11/23 Antoine Pitrou :
> On Mon, 22 Nov 2010 22:00:08 -0600
> Benjamin Peterson wrote:
>> 2010/11/22 Łukasz Langa :
>> > Wiadomość napisana przez Benjamin Peterson w dniu 2010-11-23, o godz.
>> > 00:47:
>> >
>> > No test?
>> >
>> >
>> > The tests were there already, raising ResourceWarnings.
On Tue, 23 Nov 2010 14:24:18 +
Michael Foord 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 subclassing int is a b
On 23/11/2010 14:16, Nick Coghlan wrote:
On Tue, Nov 23, 2010 at 11:50 PM, Michael Foord
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
On Tue, Nov 23, 2010 at 11:50 PM, Michael Foord
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 use something
> like this
On Mon, 22 Nov 2010 22:00:08 -0600
Benjamin Peterson wrote:
> 2010/11/22 Łukasz Langa :
> > 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,
> > they stopped doing th
On Tue, Nov 23, 2010 at 8:01 AM, Michael Foord
wrote:
> On 22/11/2010 21:08, Guido van Rossum wrote:
>>
>> On Mon, Nov 22, 2010 at 11:24 AM, Brett Cannon wrote:
>>>
>>> The problem with that is it means developers who switch to Python 3.2
>>> or whatever are suddenly going to have their tests fai
On Tue, 23 Nov 2010 00:07:09 -0500
Glyph Lefkowitz 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 does, but
On 23/11/2010 13:41, Nick Coghlan wrote:
On Tue, Nov 23, 2010 at 2:46 AM, wrote:
On 04:24 pm, solip...@pitrou.net wrote:
On Mon, 22 Nov 2010 17:08:36 +0100
Hrvoje Niksic wrote:
On 11/22/2010 04:37 PM, Antoine Pitrou wrote:
+1. The problem with int constants is that the int gets printed, no
On Tue, Nov 23, 2010 at 2:46 AM, wrote:
> On 04:24 pm, solip...@pitrou.net wrote:
>>
>> On Mon, 22 Nov 2010 17:08:36 +0100
>> Hrvoje Niksic wrote:
>>>
>>> On 11/22/2010 04:37 PM, Antoine Pitrou wrote:
>>> > +1. The problem with int constants is that the int gets printed, not
>>> > the name, whe
-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
2010/11/23 Łukasz Langa :
> 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 in the tests
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 (whi
Am 23.11.2010 11:55, schrieb Amaury Forgeot d'Arc:
> Hi,
>
> 2010/11/23 Glenn Linderman :
>> 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.
Hi,
2010/11/23 Glenn Linderman :
> 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, in order to ru
On 11/22/2010 8:33 AM, Guido van Rossum wrote:
On Sun, Nov 21, 2010 at 9:40 PM, Glenn Linderman 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, nor do I know where
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 p
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.reedy
>> wrote:
>>> Author: terry.reedy
>>> Date: Tue Nov 23 07:07:04 2010
>>> New Revision: 86703
>>>
>>> Log:
>>> Issue 9222 Fix filetypes fo
96 matches
Mail list logo
