On 24.05.2011 00:17, victor.stinner wrote:
> http://hg.python.org/cpython/rev/e44b851d0a2b
> changeset: 70323:e44b851d0a2b
> parent: 70321:202d973e8bf5
> user:Victor Stinner
> date:Tue May 24 00:16:16 2011 +0200
> summary:
> Issue #11377: platform.popen() emits a Deprecati
On Tue, May 24, 2011 at 10:08 AM, Victor Stinner
wrote:
> It's trivial to replace a call to codecs.open() by a call to open(),
> because the two API are very close. The main different is that
> codecs.open() doesn't support universal newline, so you have to use
> open(..., newline='') to keep the
On Tue, May 24, 2011 at 8:33 AM, Sturla Molden wrote:
> Den 24.05.2011 00:07, skrev Artur Siekielski:
>>
>> Oh, and using explicit shared memory or mmap is much harder, because
>> you have to map the whole object graph into bytes.
>
> It sounds like you need PYRO, POSH or multiprocessing's proxy o
In article <87zkmcalt8@uwakimon.sk.tsukuba.ac.jp>,
"Stephen J. Turnbull" wrote:
> Are you saying you expect Mac OS X 10.4 "Tiger" to go green once the
> bots update? If so, I'm impressed, and "thank you!" to all involved.
> Apple and MacPorts have long since washed their hands of that releas
On Tue, 24 May 2011 11:12:35 +0900, "Stephen J. Turnbull"
wrote:
> Tarek Ziadé writes:
>
> > I have now completed the cleanup and we're back on green-land for the
> > stable bots.
>
> Are you saying you expect Mac OS X 10.4 "Tiger" to go green once the
> bots update? If so, I'm impressed, a
Tarek Ziadé writes:
> I have now completed the cleanup and we're back on green-land for the
> stable bots.
Are you saying you expect Mac OS X 10.4 "Tiger" to go green once the
bots update? If so, I'm impressed, and "thank you!" to all involved.
Apple and MacPorts have long since washed their h
Hi,
In Python 2, codecs.open() is the best way to read and/or write files
using Unicode. But in Python 3, open() is preferred with its fast io
module. I would like to deprecate codecs.open() because it can be
replaced by open() and io.TextIOWrapper. I would like your opinion and
that's why I'm wri
Den 24.05.2011 00:07, skrev Artur Siekielski:
Oh, and using explicit shared memory or mmap is much harder, because
you have to map the whole object graph into bytes.
It sounds like you need PYRO, POSH or multiprocessing's proxy objects.
Sturla
___
P
2011/5/23 Guido van Rossum :
>> Anyway, I'd like to have working copy-on-write in CPython - in the
>> presence of GIL I find it important to have multiprocess programs
>> optimized (and I think it's a common idiom that a parent process
>> prepares some big data structure, and child "worker" process
On Mon, May 23, 2011 at 1:55 PM, Artur Siekielski
wrote:
> Ok, I managed to make a quick but working patch (sufficient to get
> working interpreter, it segfaults for extension modules). It uses the
> "ememoa" allocator (http://code.google.com/p/ememoa/) which seems a
> reasonable pool allocator. T
Ok, I managed to make a quick but working patch (sufficient to get
working interpreter, it segfaults for extension modules). It uses the
"ememoa" allocator (http://code.google.com/p/ememoa/) which seems a
reasonable pool allocator. The patch: http://dpaste.org/K8en/. The
main obstacle was that ther
On 5/23/2011 1:20 PM, Ethan Furman wrote:
Glyph Lefkowitz wrote:
In fact, I feel like I would want to push in the opposite direction:
don't treat one-byte bytes slices less like integers; I wish I could
more easily treat n-byte sequences _more_ like integers! :). More
protocols have 2-byte or 4-
Den 23.05.2011 06:59, skrev "Martin v. Löwis":
My expectation is that your approach would likely make the issues
worse in a multi-CPU setting. If you put multiple reference counters
into a contiguous block of memory, unrelated reference counters will
live in the same cache line. Consequentially,
On Mon, May 23, 2011 at 8:48 AM, Tarek Ziadé wrote:
> On Mon, May 23, 2011 at 3:00 AM, Bill Janssen wrote:
>> Tarek Ziadé wrote:
>>
>>> Yes, I am aware of this. I have fixed today most remaining issues, and
>>> fixing the final ones right now.
>>
>> Just FYI: the "AMD64 Snow Leopard" buildbot a
Glyph Lefkowitz wrote:
In fact, I feel like I would want to push in the opposite direction:
don't treat one-byte bytes slices less like integers; I wish I could
more easily treat n-byte sequences _more_ like integers! :). More
protocols have 2-byte or 4-byte network-endian packed integers embe
On Mon, May 23, 2011 at 10:40 AM, Barry Warsaw wrote:
> You're not required to run the default desktop (Unity) of course. There are
> several options out of the box, including the classic desktop and Unity 2D,
> and there are a wide range of supported derivatives of Ubuntu offering
> additional d
Okay, this reply is getting off-topic, so I won't belabor the point (please
email me directly if you want to discuss further).
On May 23, 2011, at 08:25 AM, Fred Drake wrote:
>2011/5/23 Łukasz Langa :
>> The new Ubuntu already ships with Python 3.2.
>
>Uptake on Ubuntu 11.04 will take longer than
On Mon, May 23, 2011 at 2:15 AM, Nick Coghlan wrote:
> On Sat, May 21, 2011 at 7:47 AM, "Martin v. Löwis" wrote:
>>> As Jesse has said, there is an RFP in development to improve
>>> python.org to the point where we can self-host blogs and the like and
>>> deal with the associated user account adm
2011/5/23 Łukasz Langa :
> The new Ubuntu already ships with Python 3.2.
Uptake on Ubuntu 11.04 will take longer than 10.10 uptake, given the
reliability issues and the reaction to the new user interface.
That's not to say it won't be significant, but the strength of the
indicator may be less sig
2011/5/23 Tarek Ziadé :
> 2011/5/23 Łukasz Langa :
> ...
>>
>> I've heard you're targetting 2.4 compatibility so be prepared that this is
>> not going to be easy.
>
> yeah well, we might raise the bar to 2.5 and use some __future__
> statements. I am not sure that keeping 2.4 support is that usefu
2011/5/23 Łukasz Langa :
...
>
> I've heard you're targetting 2.4 compatibility so be prepared that this is
> not going to be easy.
yeah well, we might raise the bar to 2.5 and use some __future__
statements. I am not sure that keeping 2.4 support is that useful
anymore.
Cheers
Tarek
--
Tarek Z
Wiadomość napisana przez Tarek Ziadé w dniu 2011-05-23, o godz. 12:58:
> 2011/5/23 Łukasz Langa :
> ..
>> I'm maintaining a configparser 3.2+ backport for 2.6-2.7 using 3to2.
>
> Do you backport to 3.1 ?
>
Not really. I personally think people already using py3k will migrate sooner
(even if t
2011/5/23 Łukasz Langa :
..
> I'm maintaining a configparser 3.2+ backport for 2.6-2.7 using 3to2.
Do you backport to 3.1 ?
..
>
> There's some documentation there on the conversion process I came up with.
Awesome, will look up, thanks
>
> As for distutils2, I was already contacted by Éric Arau
Wiadomość napisana przez Tarek Ziadé w dniu 2011-05-23, o godz. 11:58:
> Hey,
>
> Now that packaging has landed, the distutils2 repo is going to be
> re-seted and will be the python 2.x / 3.1 / 3.2 backport of packaging.
>
> In theory, we want to automate the extraction of packaging from the
>
Hey,
Now that packaging has landed, the distutils2 repo is going to be
re-seted and will be the python 2.x / 3.1 / 3.2 backport of packaging.
In theory, we want to automate the extraction of packaging from the
stdlib and a few other modules, and run 3to2 at install time. Or
should I say 3.3tosome
On 20/05/2011 22:56, "Martin v. Löwis" wrote:
TBH I think the less attractive we can make os.access() look the
better. It uses the real uid instead of the effective uid, it
encourages LBYL behavior, the outcome may be incorrect, it doesn't
work on Windows... The ONLY reason to ever use it is in a
26 matches
Mail list logo
