On Wed, Apr 18, 2012 at 8:25 AM, Victor Stinner
wrote:
> Ok ok, resolution / accuracy / precision are confusing (or at least
> not well known concepts).
Maybe not to us, but in fields like astronomy and mechanical
engineering there are commonly accepted definitions:
Resolution: the smallest dif
Hi,
On Tue, Apr 17, 2012 at 8:48 PM, raymond.hettinger
wrote:
> http://hg.python.org/cpython/rev/d229032dc213
> changeset: 76387:d229032dc213
> branch: 2.7
> user: Raymond Hettinger
> date: Tue Apr 17 22:48:06 2012 -0400
> summary:
> Clean-up the SQLite introduction.
>
> fi
I'll do it. Give me a few days (tomorrow is fully booked with horrible
meetings).
On Tue, Apr 17, 2012 at 5:06 PM, Victor Stinner
wrote:
>> Here is a simplified version of the first draft of the PEP 418. The
>> full version can be read online.
>> http://www.python.org/dev/peps/pep-0418/
>>
>> The
> Here is a simplified version of the first draft of the PEP 418. The
> full version can be read online.
> http://www.python.org/dev/peps/pep-0418/
>
> The implementation of the PEP can be found in this issue:
> http://bugs.python.org/issue14428
The PEP is now fully ready: I just finished the impl
On 17Apr2012 08:35, R. David Murray wrote:
| On Tue, 17 Apr 2012 14:48:22 +1000, Cameron Simpson wrote:
| > On 16Apr2012 01:25, Victor Stinner wrote:
| > | I suppose that most people don't care that "resolution" and
| > | "precision" are different things.
| >
| > If we're using the same definit
On 18Apr2012 00:18, Chris Angelico wrote:
| On Tue, Apr 17, 2012 at 2:48 PM, Cameron Simpson wrote:
| > On 16Apr2012 01:25, Victor Stinner wrote:
| > | I suppose that most people don't care that "resolution" and
| > | "precision" are different things.
| >
| > If we're using the same definitions
> I think what the user cares about is "what is the smallest tick that
> this clock result will faithfully represent?". If the number of bits
> returned is larger than the clock accuracy, you want the clock accuracy.
> If the number of bits returned is smaller than the clock accuracy,
> you want t
+1 here. Previously, it wasn't a reasonable requirement, since CPython
itself didn't comply with it.
--
Sent from my phone, thus the relative brevity :)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
On 4/17/2012 2:01 PM, Brett Cannon wrote:
Isn't it clearer to say
``sys.path_importer_cache[path] is None`` than
``isinstance(sys.path_importer_cache[path], imp.NullImporter)``?
Yes. Great work. Thanks for helping with the Idle breakage.
--
Terry Jan Reedy
+1 for initial proposition.
On Tue, Apr 17, 2012 at 6:59 PM, Brett Cannon wrote:
> Anyone other than Eric have something to say on this proposal? Obviously the
> discussion went tangential before I saw a clear consensus that what I was
> proposing was fine with people.
>
>
> On Sat, Apr 14, 2012
On Tue, Apr 17, 2012 at 8:30 PM, Antoine Pitrou wrote:
> On Tue, 17 Apr 2012 17:22:57 +
> Kristján Valur Jónsson wrote:
> > >
> > > We are all consenting adults. Everything is allowed - you just have to
> live with
> > > the consequences.
> >
> > Well, we specifically decided that objects wi
On Tue, Apr 17, 2012 at 13:39, Antoine Pitrou wrote:
> On Tue, 17 Apr 2012 11:41:32 -0400
> Brett Cannon wrote:
> >
> > Actually Cython would help with a subtle maintenance burden of
> maintaining
> > *any* C code for import. Right now,
> > Python/import.c:PyImport_ImportModuleLevelObject() is a
On Tue, 17 Apr 2012 17:22:57 +
Kristján Valur Jónsson wrote:
> >
> > We are all consenting adults. Everything is allowed - you just have to live
> > with
> > the consequences.
>
> Well, we specifically decided that objects with __del__ methods that are part
> of a cycle cannot be run.
> Th
> -Original Message-
>
> No, that's not the case at all. As Antoine explains in the issue, there are
> plenty of ways in which Python code can be run when breaking a cycle. Not
> only weakrefs, but also objects released as a consequence of tp_clear which
> weren't *in* the cycle (but hun
On Tue, Apr 17, 2012 at 13:45, Philip Jenvey wrote:
>
> On Apr 14, 2012, at 1:03 PM, Brett Cannon wrote:
>
> > And lastly, sticking None in sys.path_importer_cache would no longer
> mean "do the implicit thing" and instead would mean the same as
> NullImporter does now (which also means import ca
On Apr 14, 2012, at 1:03 PM, Brett Cannon wrote:
> And lastly, sticking None in sys.path_importer_cache would no longer mean "do
> the implicit thing" and instead would mean the same as NullImporter does now
> (which also means import can put None into sys.path_importer_cache instead of
> Null
On Tue, 17 Apr 2012 11:41:32 -0400
Brett Cannon wrote:
>
> Actually Cython would help with a subtle maintenance burden of maintaining
> *any* C code for import. Right now,
> Python/import.c:PyImport_ImportModuleLevelObject() is an accelerated C
> version of importlib.__import__() through checking
Anyone other than Eric have something to say on this proposal? Obviously
the discussion went tangential before I saw a clear consensus that what I
was proposing was fine with people.
On Sat, Apr 14, 2012 at 16:56, Brett Cannon wrote:
> An open issue in PEP 302 is whether to require __loader__ at
The only people to bring up worries about this thread were Eric and Nick
and they both seem fine with making stuff explicit and changing the meaning
of None in sys.path_importer_cache, so I have created
http://bugs.python.org/issue14605 and will plan on implementing the ideas
for it before Python 3
On Tue, Apr 17, 2012 at 06:43, Eric V. Smith wrote:
> On 4/17/2012 5:52 AM, Antoine Pitrou wrote:
> > On Mon, 16 Apr 2012 20:41:56 -0400
> > Brett Cannon wrote:
> >> On Mon, Apr 16, 2012 at 20:27, Antoine Pitrou
> wrote:
> >>
> >>> On Tue, 17 Apr 2012 01:11:14 +0200
> >>> Georg Brandl wrote:
>
On Tue, Apr 17, 2012 at 05:53, Antoine Pitrou wrote:
> On Tue, 17 Apr 2012 04:11:31 +0200
> brett.cannon wrote:
> > http://hg.python.org/cpython/rev/3b5b4b4bb43c
> > changeset: 76371:3b5b4b4bb43c
> > user:Brett Cannon
> > date:Mon Apr 16 22:11:25 2012 -0400
> > summary:
> >
On Apr 17, 2012, at 08:25 AM, R. David Murray wrote:
>On Tue, 17 Apr 2012 08:53:43 +0200, Matej Cepl wrote:
>> On 16.4.2012 18:10, Nam Nguyen wrote:
>> > a_list[pos + 1 : -1]
>>
>> or other way around
>>
>> a_list[pos+1:-1]
>
>
>That's what I always use. No spaces inside the brackets for me :)
What I want to know is, why is this limitation in place? Here are
two possibilities:
1) "The order of calling finalizers in a cycle is undefined so
it is not a solvable problem". But this would allow a single
object, with only internal cycles to be collected. Currently this
is not
On Tue, Apr 17, 2012 at 12:14 AM, Paul Moore wrote:
> On 16 April 2012 17:10, Nam Nguyen wrote:
>> PEP 8 suggests no extra spaces after and before square brackets, and
>> colons. So code like this is appropriate:
>>
>> a_list[1:3]
>>
>> But I find it less readable in the case of:
>>
>> a_list[pos
On Tue, Apr 17, 2012 at 2:48 PM, Cameron Simpson wrote:
> On 16Apr2012 01:25, Victor Stinner wrote:
> | I suppose that most people don't care that "resolution" and
> | "precision" are different things.
>
> If we're using the same definitions we discussed offline, where
>
> - resolution is the un
Paul Moore dixit (2012-04-17, 08:14):
> On 16 April 2012 17:10, Nam Nguyen wrote:
> > PEP 8 suggests no extra spaces after and before square brackets, and
> > colons. So code like this is appropriate:
> >
> > a_list[1:3]
> >
> > But I find it less readable in the case of:
> >
> > a_list[pos + 1:-
On Tue, 17 Apr 2012 14:48:22 +1000, Cameron Simpson wrote:
> On 16Apr2012 01:25, Victor Stinner wrote:
> | I suppose that most people don't care that "resolution" and
> | "precision" are different things.
>
> If we're using the same definitions we discussed offline, where
>
> - resolution is
On Tue, 17 Apr 2012 08:53:43 +0200, Matej Cepl wrote:
> On 16.4.2012 18:10, Nam Nguyen wrote:
> > a_list[pos + 1 : -1]
>
> or other way around
>
> a_list[pos+1:-1]
That's what I always use. No spaces inside the brackets for me :)
If the expression gets unreadable that way, factor it out.
--
On Tue, 17 Apr 2012 01:11:14 +0200, Georg Brandl wrote:
> On 16.04.2012 18:15, R. David Murray wrote:
> > I don't see how depending on Cython is better than depending on having
> > an existing Python.
>
> No, it's not just an existing Python, it is (at least currently) the same
> version of Pytho
Hello there.
For those familiar with the intricacies of the gcmodule.c, I would like to draw
your attention to http://bugs.python.org/issue9141.
I would like to consult with you to find out more about finalizers/gc in order
to improve the in-file documentation.
Traditionally, it has not been po
On 4/17/2012 5:52 AM, Antoine Pitrou wrote:
> On Mon, 16 Apr 2012 20:41:56 -0400
> Brett Cannon wrote:
>> On Mon, Apr 16, 2012 at 20:27, Antoine Pitrou wrote:
>>
>>> On Tue, 17 Apr 2012 01:11:14 +0200
>>> Georg Brandl wrote:
No, it's not just an existing Python, it is (at least current
On Tue, 17 Apr 2012 04:11:31 +0200
brett.cannon wrote:
> http://hg.python.org/cpython/rev/3b5b4b4bb43c
> changeset: 76371:3b5b4b4bb43c
> user:Brett Cannon
> date:Mon Apr 16 22:11:25 2012 -0400
> summary:
> Issue #13959: Re-implement imp.load_source() in imp.py.
>
> files:
>
On Mon, 16 Apr 2012 20:41:56 -0400
Brett Cannon wrote:
> On Mon, Apr 16, 2012 at 20:27, Antoine Pitrou wrote:
>
> > On Tue, 17 Apr 2012 01:11:14 +0200
> > Georg Brandl wrote:
> > >
> > > No, it's not just an existing Python, it is (at least currently) the same
> > > version of Python being buil
On Sun, Apr 15, 2012 at 6:18 PM, Victor Stinner wrote:
> > Here is a simplified version of the first draft of the PEP 418. The
> > full version can be read online.
> > http://www.python.org/dev/peps/pep-0418/
>
> FYI there is no time.thread_time() function. It would only be
> available on Windows
On 16 April 2012 17:10, Nam Nguyen wrote:
> PEP 8 suggests no extra spaces after and before square brackets, and
> colons. So code like this is appropriate:
>
> a_list[1:3]
>
> But I find it less readable in the case of:
>
> a_list[pos + 1:-1]
>
> The colon is seemingly lost in the right.
>
> Woul
On 16.4.2012 18:10, Nam Nguyen wrote:
a_list[pos + 1 : -1]
or other way around
a_list[pos+1:-1]
?
Matěj
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mai
36 matches
Mail list logo
