Barry Warsaw wrote:
> Greetings from Pycon 2008!
>
> Neal Norwitz and I have worked out the schedule for Python 2.6 and 3.0,
> which will be released in lockstep. We will be following a monthly
> release schedule, with releases to occur on the first Wednesday of the
> month. We'll move to a 2
This is something that I've been pondering over for a while now, but I
haven't been able to come to any strong conclusions. I'd appreciate
some comment, and possibly a bit of clarification in the documentation
for migrating to 3.0.
I'm basically an end user of Python. I don't write libraries or
fr
Paul Moore wrote:
> As I said at the start, I don't have any good answers. But would it be
> worth maintaining something like a wiki page of key libraries and
> their expectations for moving to 3.0? It might at least make people
> aware of reasonable timescales, and set some expectations for chroni
Dnia 17-03-2008, Pn o godzinie 11:56 -0600, Adam Olsen pisze:
> I've replaced __del__ API (which resurrected objects) with a
> __finalize__/__finalizeattrs__ API (which doesn't). Attributes listed
> in __finalizeattrs__ are proxied into a core object, a finalizer
> thread is given a reference to
> This is something that I've been pondering over for a while now, but I
> haven't been able to come to any strong conclusions. I'd appreciate
> some comment, and possibly a bit of clarification in the documentation
> for migrating to 3.0.
As Nick says: Don't worry at all about migrating to 3.0. I
On 18/03/2008, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > This is something that I've been pondering over for a while now, but I
> > haven't been able to come to any strong conclusions. I'd appreciate
> > some comment, and possibly a bit of clarification in the documentation
> > for migrating
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 18, 2008, at 2:04 AM, Travis Oliphant wrote:
>
> Hey Barry,
>
> Thanks for putting this PEP together. This is really helpful.
Hi Travis... thanks!
> I didn't see discussion of PEP 3118 and it's features back-ported to
> Python 2.6. I've alre
On Tue, Mar 18, 2008 at 6:39 AM, Marcin 'Qrczak' Kowalczyk
<[EMAIL PROTECTED]> wrote:
> Dnia 17-03-2008, Pn o godzinie 11:56 -0600, Adam Olsen pisze:
>
> > I've replaced __del__ API (which resurrected objects) with a
> > __finalize__/__finalizeattrs__ API (which doesn't). Attributes listed
> >
When I do a relative star import, I current get
SyntaxError: 'import *' not allowed with 'from .'
What's the reason for this restriction?
Is it ok to remove it?
I encountered the issue while porting Django. In
django/newforms/__init__.py, they do
from widgets import *
from fields import *
from
I don't recall the reason; it may simply be due to the complexity, or
possibly it would have made the _import__ API even uglier.
I'm fine with removing the restriction; your use case is compelling.
On Tue, Mar 18, 2008 at 10:23 AM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> When I do a relati
On Tue, Mar 18, 2008 at 8:32 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> I don't recall the reason; it may simply be due to the complexity, or
> possibly it would have made the _import__ API even uglier.
>
I don't recall any such issues, and I can't imagine them now. The '.' is
resolved bef
On Tue, Mar 18, 2008, "Martin v. L?wis" wrote:
>
> When I do a relative star import, I current get
>
> SyntaxError: 'import *' not allowed with 'from .'
>
> What's the reason for this restriction?
It was the first step in removing the ability to use "from *" at all. I
don't have time right now
On Tue, Mar 18, 2008 at 9:21 AM, Steven Bethard
<[EMAIL PROTECTED]> wrote:
> On Tue, Mar 18, 2008 at 6:39 AM, Marcin 'Qrczak' Kowalczyk
> <[EMAIL PROTECTED]> wrote:
> > Dnia 17-03-2008, Pn o godzinie 11:56 -0600, Adam Olsen pisze:
> >
> > > I've replaced __del__ API (which resurrected objects)
Adam Olsen schrieb:
> On Tue, Mar 18, 2008 at 9:21 AM, Steven Bethard
> <[EMAIL PROTECTED]> wrote:
>> On Tue, Mar 18, 2008 at 6:39 AM, Marcin 'Qrczak' Kowalczyk
>> <[EMAIL PROTECTED]> wrote:
>> > Dnia 17-03-2008, Pn o godzinie 11:56 -0600, Adam Olsen pisze:
>> >
>> > > I've replaced __del__ AP
Barry Warsaw schrieb:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Mar 18, 2008, at 2:04 AM, Travis Oliphant wrote:
>>
>> Hey Barry,
>>
>> Thanks for putting this PEP together. This is really helpful.
>
> Hi Travis... thanks!
>
>> I didn't see discussion of PEP 3118 and it's feature
I keep forgetting to reply to the list:
This is great news. I was getting ready to submit a patch to fix the
Unicode handling in simplejson (which I will probably do anyway), but
I'm interested in making sure whichever lib will hit the standard
library has a correct implementation.
Doug
O
On Tue, Mar 18, 2008 at 11:17 AM, John Millikin <[EMAIL PROTECTED]> wrote:
> > Possible features for 2.6
> > New modules in the standard library:
> > - JSON implementation
> >
> Have there been any plans made for which one? All of the
No. This was something I added as a nice to ha
> It was the first step in removing the ability to use "from *" at all. I
> don't have time right now to find the discussion, but I can do that later
> if you want.
Thanks - that's what I expected; no need to dig out further details.
Regards,
Martin
__
On Tue, Mar 18, 2008 at 11:59 AM, Benjamin Peterson
<[EMAIL PROTECTED]> wrote:
>
>
>
> On Tue, Mar 18, 2008 at 10:49 AM, Aahz <[EMAIL PROTECTED]> wrote:
> >
> > On Tue, Mar 18, 2008, "Martin v. L?wis" wrote:
> > >
> > > When I do a relative star import, I current get
> > >
> > > SyntaxError: 'impor
On Tue, Mar 18, 2008 at 10:15 AM, Thomas Heller <[EMAIL PROTECTED]> wrote:
> Adam Olsen schrieb:
>
>
> > On Tue, Mar 18, 2008 at 9:21 AM, Steven Bethard
> > <[EMAIL PROTECTED]> wrote:
> >> On Tue, Mar 18, 2008 at 6:39 AM, Marcin 'Qrczak' Kowalczyk
> >> <[EMAIL PROTECTED]> wrote:
> >> > Dnia 1
On Tue, Mar 18, 2008 at 10:49 AM, Aahz <[EMAIL PROTECTED]> wrote:
> On Tue, Mar 18, 2008, "Martin v. L?wis" wrote:
> >
> > When I do a relative star import, I current get
> >
> > SyntaxError: 'import *' not allowed with 'from .'
> >
> > What's the reason for this restriction?
>
> It was the first
On Tue, Mar 18, 2008 at 12:21 PM, Neal Norwitz <[EMAIL PROTECTED]> wrote:
> On Tue, Mar 18, 2008 at 11:59 AM, Benjamin Peterson
> <[EMAIL PROTECTED]> wrote:
> >
> >
> >
> > On Tue, Mar 18, 2008 at 10:49 AM, Aahz <[EMAIL PROTECTED]> wrote:
> > >
> > > On Tue, Mar 18, 2008, "Martin v. L?wis" wrote:
Dnia 18-03-2008, Wt o godzinie 11:24 -0600, Adam Olsen pisze:
> If they need access to containing objects the only option is to use
> the underlying tool, deathqueues.
Deathqueues are a part of python-safethread, right?
Interesting, but just like the finalization design, the design with
weakrefs
On Tue, Mar 18, 2008 at 1:13 PM, Marcin 'Qrczak' Kowalczyk
<[EMAIL PROTECTED]> wrote:
> Dnia 18-03-2008, Wt o godzinie 11:24 -0600, Adam Olsen pisze:
>
>
> > If they need access to containing objects the only option is to use
> > the underlying tool, deathqueues.
>
> Deathqueues are a part of py
On Tue, Mar 18, 2008, Ronald Oussoren wrote:
> On 18 Mar, 2008, at 16:49, Aahz wrote:
>>On Tue, Mar 18, 2008, "Martin v. L?wis" wrote:
>>>
>>>When I do a relative star import, I current get
>>>
>>>SyntaxError: 'import *' not allowed with 'from .'
>>>
>>>What's the reason for this restriction?
>>
>>
Dnia 18-03-2008, Wt o godzinie 13:37 -0600, Adam Olsen pisze:
> What sort of blocking wait do you use? Or did you mean you don't have one?
I meant that I don't have one, I only have iteration over the whole
queue, which is equivalent to having trypop. Which prompts the question:
what are use cas
On Tue, Mar 18, 2008 at 2:04 PM, Marcin 'Qrczak' Kowalczyk
<[EMAIL PROTECTED]> wrote:
> Dnia 18-03-2008, Wt o godzinie 13:37 -0600, Adam Olsen pisze:
>
>
> > What sort of blocking wait do you use? Or did you mean you don't have one?
>
> I meant that I don't have one, I only have iteration over t
On Tue, Mar 18, 2008 at 11:43 AM, Neal Norwitz <[EMAIL PROTECTED]> wrote:
> On Tue, Mar 18, 2008 at 11:17 AM, John Millikin <[EMAIL PROTECTED]> wrote:
> > > Possible features for 2.6
> > > New modules in the standard library:
> > > - JSON implementation
> > >
> > Have there bee
[changing to: and subject: ]
On Tue, Mar 18, 2008 at 4:09 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On Tue, Mar 18, 2008 at 3:58 PM, neal.norwitz
> <[EMAIL PROTECTED]> wrote:
> > Get this test to pass (UserList/UserDict no longer exist and caused a
> skip).
>
> I think the automatic s
Dnia 18-03-2008, Wt o godzinie 14:32 -0600, Adam Olsen pisze:
> The finalizer thread blocks until something's been deleted.
Ok. If this is the only use case, I feel quite safe not having this,
because my finalizers are implemented independently (and a finalizer
thread is created on demand, which
Both modules have a crc32 function. The zlib version is faster when zlib
has been compiled optimally or about the same when zlib is old or uses its C
code.
Should we ditch the binascii.crc32 version in py3k?
64bit Linux (CentOS 5.1):
$ python2.4 -m timeit 'foo="abcdefghijklmnop"*10' 'import bin
On Tue, Mar 18, 2008 at 4:04 PM, Marcin 'Qrczak' Kowalczyk
<[EMAIL PROTECTED]> wrote:
> Dnia 18-03-2008, Wt o godzinie 14:32 -0600, Adam Olsen pisze:
>
>
> > The finalizer thread blocks until something's been deleted.
>
> Ok. If this is the only use case, I feel quite safe not having this,
> bec
Dnia 18-03-2008, Wt o godzinie 16:22 -0600, Adam Olsen pisze:
> Search for info on java's deprecated Thread.stop() if you're not
> already familiar with the problems it has.
The problem with Java's Thread.stop() is that it is not possible to
block it in a given region, and that it is not possible
On Tue, Mar 18, 2008 at 4:52 PM, Marcin 'Qrczak' Kowalczyk
<[EMAIL PROTECTED]> wrote:
> Dnia 18-03-2008, Wt o godzinie 16:22 -0600, Adam Olsen pisze:
>
>
> > Search for info on java's deprecated Thread.stop() if you're not
> > already familiar with the problems it has.
>
> The problem with Java'
Aahz wrote:
> [*] General note to the list: see how I'm using both the PEP number and
> the title.
Maybe the Python-Dev list server could pass everything
through a filter that looks for "PEP " references
and inserts the PEP title after them? :-)
--
Greg
__
Adam Olsen wrote:
> I'd tend to assume only *purely* functional languages should have
> asynchronous interrupts. Any imperative language with them is
> suspect.
Yet there are situations where *not* having any such thing
can be extremely inconvenient.
If I'm performing some background calculation
On Tue, Mar 18, 2008 at 6:47 PM, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Adam Olsen wrote:
> > I'd tend to assume only *purely* functional languages should have
> > asynchronous interrupts. Any imperative language with them is
> > suspect.
>
> Yet there are situations where *not* having any su
Regarding putting some JSON implementation in the standard library...
I suppose anyone who uses JSON is aware of its limitations, but this was a
bit disconcerting:
>>> simplejson.loads(simplejson.dumps({1: 2}))
{u'1': 2}
Silent type conversion is a Perl thing. I would prefer it if it ra
38 matches
Mail list logo
