On 04/08/06, Ka-Ping Yee <[EMAIL PROTECTED]> wrote:
> On Thu, 3 Aug 2006, Oren Tirosh wrote:
> > The UUID module uses network byte order, regardless of the platform
> > byte order. On little-endian platforms like Windows the ".bytes"
> > property of UUID obje
The UUID module uses network byte order, regardless of the platform
byte order. On little-endian platforms like Windows the ".bytes"
property of UUID objects is not compatible with the memory layout of
UUIDs:
>>> import uuid
>>> import pywintypes
>>> s = '{00112233-4455-6677-8899-aabbccddeeff}'
>>
On 10/31/05, Antoine Pitrou <[EMAIL PROTECTED]> wrote:
>
> > It allows everything in Python to be both mutable and hashable,
>
> I don't understand, since it's already the case. Any user-defined object
> is at the same time mutable and hashable.
By default, user-defined objects are equal iff they
On 10/28/05, Neil Hodgson <[EMAIL PROTECTED]> wrote:
>I used to work on software written by Japanese and English speakers
> at Fujitsu with most developers being Japanese. The rules were that
> comments could be in Japanese but identifiers were only allowed to
> contain ASCII characters. Most v
On 9/12/05, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Oren Tirosh wrote:
>
> > perhaps the Python 3 executable should have a different name as part
> > of the standard distribution? I suggest "py" / "py.exe"
>
> Or "python3"? EIBTI :-
On 9/11/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
...
> But just installing python3.0 as python and expecting
> nothing will break is not a goal -- it would be too constraining.
It should be expected that many users will keep both 2.x and 3 side by
side for quite a long time. Instead of havi
On 9/1/05, Robert Kern <[EMAIL PROTECTED]> wrote:
> Oren Tirosh wrote:
>
> > While a lot of existing code will break on 3.0 it is still generally
> > possible to write code that will run on both 2.x and 3.0: use only the
> > "proper" forms above, do no
Most of the changes in PEP 3000 are tightening up of "There should be
one obvious way to do it.":
* Remove multiple forms of raising exceptions, leaving just "raise instance"
* Remove exec as statement, leaving the compatible tuple/call form.
* Remove <>, ``, leaving !=, repr
etc.
Other changes
On 30/08/05, JustFillBug <[EMAIL PROTECTED]> wrote:
> On 2005-08-30, Anthony Baxter <[EMAIL PROTECTED]> wrote:
> > On Tuesday 30 August 2005 11:26, Raymond Hettinger wrote:
> >> > My major issue is with the names - partition() doesn't sound right to
> >> > me.
> >>
> >> FWIW, I am VERY happy with t
On 6/27/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Reinhold Birkenfeld wrote:
> > 1152248:
> > In order to read "records" separated by something other than newline, file
> > objects
> > should either support an additional parameter (the separator) to
> > (x)readlines(),
> > or gain an addition
On 6/26/05, Adam Olsen <[EMAIL PROTECTED]> wrote:
...
> To resolve these problems I propose adding lightweight cooperative
> threads to Python.
Speaking of lightweight cooperative threads - has anyone recently
tried to build Python with the pth option? It doesn't quite work out
of the box. How m
Please don't invent new serialization formats. I think we have enough
of those already.
The RFE suggests that "the protocol is specified in the documentation,
precisely enough to write interoperating implementations in other
languages". If interoperability with other languages is really the
issue,
I suggest using a variation on the consumer interface, as described by
Fredrik Lundh at http://effbot.org/zone/consumer.htm :
.next() -- stays .next()
.__next__(arg) -- becomes .feed(arg)
.__exit__(StopIteration, ...) -- becomes .close()
.__exit__(..,..,..) -- becomes .feed(exc_info=(..,..,..))
13 matches
Mail list logo
