On Thu, Apr 7, 2011 at 2:55 PM, Glenn Linderman wrote:
> __version__ = "7.9.7" # replaced by "packaging"
>
> If you don't upload your module to PyPI, then you can do whatever you
> want with your versioning info. If you *do* upload it to PyPI, then
> part of doing so properly is to package it
Brett Cannon, 06.04.2011 19:40:
On Tue, Apr 5, 2011 at 05:01, Nick Coghlan wrote:
However, there actually *is* a significant semantic discrepancy in the
heapq case, which is that py_heapq is duck-typed, while c_heapq is
not:
TypeError: heap argument must be a list
That's true. I will re-word
On 4/6/2011 9:08 PM, Nick Coghlan wrote:
On Thu, Apr 7, 2011 at 7:58 AM, Glenn Linderman wrote:
Perhaps a different technique would be that if packaging is in use, that it
could somehow inject the version from setup.cfg into the module, either by
tweaking the source as it gets packaged, or inst
On Thu, Apr 7, 2011 at 1:37 PM, anatoly techtonik wrote:
> Is it a good idea to have code highlighting in tracker?
The tracker doesn't display code. Only the code review tool and the
repository browser display code (and syntax highlighting is useful but
not essential for those use cases, just as
On Thu, Apr 7, 2011 at 7:40 AM, Antoine Pitrou wrote:
> For the record, I've tried to make the force build form clearer on the
> buildbot Web UI. See e.g.:
> http://www.python.org/dev/buildbot/all/builders/x86%20OpenIndiana%20custom
Looks good - trying it out on my LHS precedence correction branc
On Thu, Apr 7, 2011 at 7:58 AM, Glenn Linderman wrote:
> Perhaps a different technique would be that if packaging is in use, that it
> could somehow inject the version from setup.cfg into the module, either by
> tweaking the source as it gets packaged, or installed, or tweaking the
> module as/aft
2011/4/6 anatoly techtonik :
> Is it a good idea to have code highlighting in tracker?
Why would we need it?
--
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http:
Is it a good idea to have code highlighting in tracker?
I'd like to gather independent unbiased opinion for a little research
of Python development. Unfortunately, there is no way to create a
poll, but if you just say yes or no without reading all other comments
- that would be fine. Thanks.
--
a
On 4/6/2011 2:54 PM, Terry Reedy wrote:
I believe that at the time of that decision, the Python [heapq] code was only
intended for humans, like the Python (near) equivalents in the itertools
docs to C-coded itertool functions. Now that we are aiming to have
stdlib Python code be a reference impl
On Apr 6, 2011, at 4:44 PM, s...@pobox.com wrote:
>Brett> How about the test suite needs to have 100% test coverage (or as
>Brett> close as possible) on the pure Python version?
>
> Works for me, but you will have to define what "100%" is fairly clearly.
> 100% of the lines get executed?
On Wed, 06 Apr 2011 18:05:57 -0400, Tres Seaver wrote:
> On 04/06/2011 04:37 PM, Antoine Pitrou wrote:
> > On Wed, 6 Apr 2011 13:22:09 -0700 Brett Cannon wrote:
> >> How about the test suite needs to have 100% test coverage (or as close as
> >> possible) on the pure Python version?
> >
> > Let's
On Apr 6, 2011, at 2:40 PM, Antoine Pitrou wrote:
> For the record, I've tried to make the force build form clearer on the
> buildbot Web UI. See e.g.:
> http://www.python.org/dev/buildbot/all/builders/x86%20OpenIndiana%20custom
Much improved. Thanks.
Raymond
___
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/06/2011 04:37 PM, Antoine Pitrou wrote:
> On Wed, 6 Apr 2011 13:22:09 -0700
> Brett Cannon wrote:
>> On Wed, Apr 6, 2011 at 12:45, Raymond Hettinger >> wrote:
>>
>>>
>>> On Apr 6, 2011, at 10:39 AM, Brett Cannon wrote:
Since people are taki
On 4/6/2011 7:26 AM, Nick Coghlan wrote:
On Wed, Apr 6, 2011 at 6:22 AM, Glenn Linderman wrote:
With more standardization of versions, should the version module be promoted
to stdlib directly?
When Tarek lands "packaging" (i.e. what distutils2 becomes in the
Python 3.3 stdlib), the standardise
On Thu, Apr 7, 2011 at 6:22 AM, Brett Cannon wrote:
> How about the test suite needs to have 100% test coverage (or as close as
> possible) on the pure Python version? That will guarantee that the C code
> which passes that level of test detail is as semantically equivalent as
> possible. It also
Hello,
For the record, I've tried to make the force build form clearer on the
buildbot Web UI. See e.g.:
http://www.python.org/dev/buildbot/all/builders/x86%20OpenIndiana%20custom
Regards
Antoine.
___
Python-Dev mailing list
Python-Dev@python.org
ht
On Apr 6, 2011, at 1:22 PM, Brett Cannon wrote:
> How about the test suite needs to have 100% test coverage (or as close as
> possible) on the pure Python version? That will guarantee that the C code
> which passes that level of test detail is as semantically equivalent as
> possible. It also
On Apr 6, 2011, at 1:22 PM, Brett Cannon wrote:
>
>
> On Wed, Apr 6, 2011 at 12:45, Raymond Hettinger
> wrote:
>
> On Apr 6, 2011, at 10:39 AM, Brett Cannon wrote:
> > Since people are taking my "semantically identical" point too strongly for
> > what I mean (there is a reason I said "excep
Brett> How about the test suite needs to have 100% test coverage (or as
Brett> close as possible) on the pure Python version?
Works for me, but you will have to define what "100%" is fairly clearly.
100% of the lines get executed? All the branches are taken? Under what
circumstances mig
On Wed, 6 Apr 2011 13:22:09 -0700
Brett Cannon wrote:
> On Wed, Apr 6, 2011 at 12:45, Raymond Hettinger > wrote:
>
> >
> > On Apr 6, 2011, at 10:39 AM, Brett Cannon wrote:
> > > Since people are taking my "semantically identical" point too strongly
> > for what I mean (there is a reason I said "
James Y Knight, 06.04.2011 17:03:
On Apr 6, 2011, at 10:08 AM, Nick Coghlan wrote:
Argument handling is certainly a tricky one - getting positional only
arguments requires a bit of a hack in pure Python code (accepting
*args and unpacking the arguments manually), but it comes reasonably
naturall
On Wed, Apr 6, 2011 at 12:45, Raymond Hettinger wrote:
>
> On Apr 6, 2011, at 10:39 AM, Brett Cannon wrote:
> > Since people are taking my "semantically identical" point too strongly
> for what I mean (there is a reason I said "except in cases
> > where implementation details of a VM prevents [se
On Apr 6, 2011, at 10:39 AM, Brett Cannon wrote:
> Since people are taking my "semantically identical" point too strongly for
> what I mean (there is a reason I said "except in cases
> where implementation details of a VM prevents [semantic equivalency]
> entirely"), how about we change the requ
Brett Cannon wrote:
> * We also suffer from inconsistency in choice of
> exceptions (i.e. overly large sequence indices
> raising either an IndexError, OverflowError, or
> ValueError).
>
>
> Once again, a general issue in our C code and not special to this PEP.
Not only in th
On 4/6/2011 1:24 PM, Maciej Fijalkowski wrote:
No worries, it wasn't even my code. Someone
donated it. The was a discusion on python-dev
and collective agreement to allow it to have
semantic differences that would let it run faster.
IIRC, the final call was made by Uncle Timmy.
...
And, for t
Am 06.04.2011 03:39, schrieb exar...@twistedmatrix.com:
> On 5 Apr, 07:58 pm, mar...@v.loewis.de wrote:
>>> Does this mean new versions of distutils let you build_ext with any C
>>> compiler, instead of enforcing the same compiler as it has done
>>> previously?
>>
>> No, it doesn't. distutils was c
On Apr 6, 2011, at 10:24 AM, Maciej Fijalkowski wrote:
>
> "I saw no need to complicate the pure python code for this."
>
> if you complicate the C code for this, then please as well complicate
> python code for this since it's breaking stuff.
Do you really need a PEP for this one extraordinar
On Tue, Apr 5, 2011 at 05:01, Nick Coghlan wrote:
> On Tue, Apr 5, 2011 at 9:46 AM, Brett Cannon wrote:
> > try:
> > c_heapq.heappop(Spam())
> > except TypeError:
> > # "heap argument must be a list"
> > pass
> >
> > try:
> > py_heapq.heappop(Spam())
>
On Tue, Apr 5, 2011 at 12:57, Raymond Hettinger wrote:
> [Brett]
> > This PEP requires that in these instances that both
> > the Python and C code must be semantically identical
>
> Are you talking about the guaranteed semantics
> promised by the docs or are you talking about
> every possible imp
> No worries, it wasn't even my code. Someone
> donated it. The was a discusion on python-dev
> and collective agreement to allow it to have
> semantic differences that would let it run faster.
> IIRC, the final call was made by Uncle Timmy.
>
The bug link is here:
http://bugs.python.org/issue3
On Tue, Apr 5, 2011 at 06:10, Jim Jewett wrote:
> On 4/4/11, brett.cannon wrote:
> > Draft of PEP 399: Pure Python/C Accelerator Module Compatibiilty
> > Requirements
>
> > +Abstract
> > +
> > +
> > +The Python standard library under CPython contains various instances
> > +of modules i
Hello Guys,
I would like to present my proposal for the Google Summer of Code,
concerning the idea of porting the benchmarks to Python 3.x for
speed.pypy.org. I think I have successfully integrated the feedback I
got from prior discussions on the topic and I would like to hear your
opinion.
Abstra
Le 06/04/2011 03:39, exar...@twistedmatrix.com a écrit :
On 5 Apr, 07:58 pm, mar...@v.loewis.de wrote:
Does this mean new versions of distutils let you build_ext with any
C
compiler, instead of enforcing the same compiler as it has done
previously?
No, it doesn't. distutils was considered fro
On Apr 6, 2011, at 10:08 AM, Nick Coghlan wrote:
> On Wed, Apr 6, 2011 at 5:57 AM, Raymond Hettinger
> wrote:
>> [Brett]
>>> This PEP requires that in these instances that both
>>> the Python and C code must be semantically identical
>>
>> Are you talking about the guaranteed semantics
>> promi
On Thu, Apr 7, 2011 at 1:03 AM, James Y Knight wrote:
> Perhaps the argument handling for C functions ought to be enhanced to work
> like python's argument handling, instead of trying to hack it the other way
> around?
Oh, definitely. It is just that you pretty much have to use the *args
hack w
On Tue, Apr 5, 2011 at 09:05, Antoine Pitrou wrote:
>
> Hello,
>
> For the record, we have 9 stable buildbots, one of which is currently
> offline: 3 Windows, 2 OS X, 3 Linux and 1 Solaris.
> Paul Moore's XP buildbot is back in the stable stable.
> (http://www.python.org/dev/buildbot/all/waterfal
On Wed, 06 Apr 2011 15:17:05 +0100
Michael Foord wrote:
> On 05/04/2011 20:57, Raymond Hettinger wrote:
> > [snip...]
> > [Brett]
> >> (sorry, Raymond, for picking on heapq, but is
> >> was what bit the PyPy people most recently =).
> > No worries, it wasn't even my code. Someone
> > donated it.
On Thu, Apr 7, 2011 at 12:01 AM, Antoine Pitrou wrote:
> Le mercredi 06 avril 2011 à 23:55 +1000, Nick Coghlan a écrit :
>> Since it appears the intermittent failures affecting these platforms
>> have been dealt with, is it time to switch python-committers email
>> notifications back on for buildb
On Wed, Apr 6, 2011 at 6:22 AM, Glenn Linderman wrote:
> With more standardization of versions, should the version module be promoted
> to stdlib directly?
When Tarek lands "packaging" (i.e. what distutils2 becomes in the
Python 3.3 stdlib), the standardised version handling will come with
it.
>
On 05/04/2011 20:57, Raymond Hettinger wrote:
[snip...]
[Brett]
(sorry, Raymond, for picking on heapq, but is
was what bit the PyPy people most recently =).
No worries, it wasn't even my code. Someone
donated it. The was a discusion on python-dev
and collective agreement to allow it to have
s
On Wed, Apr 6, 2011 at 11:59 PM, Antoine Pitrou wrote:
> On Tue, 5 Apr 2011 12:57:13 -0700
> Raymond Hettinger wrote:
>>
>> * I would like to see a restriction on the use of
>> the concrete C API such that it is *only* used
>> when a exact type match has been found or created
>> (i.e. if so
On Wed, Apr 6, 2011 at 5:57 AM, Raymond Hettinger
wrote:
> [Brett]
>> This PEP requires that in these instances that both
>> the Python and C code must be semantically identical
>
> Are you talking about the guaranteed semantics
> promised by the docs or are you talking about
> every possible impl
Le mercredi 06 avril 2011 à 23:55 +1000, Nick Coghlan a écrit :
> On Wed, Apr 6, 2011 at 12:05 AM, Antoine Pitrou wrote:
> >
> > Hello,
> >
> > For the record, we have 9 stable buildbots, one of which is currently
> > offline: 3 Windows, 2 OS X, 3 Linux and 1 Solaris.
> > Paul Moore's XP buildbot
On Tue, 5 Apr 2011 12:57:13 -0700
Raymond Hettinger wrote:
>
> * I would like to see a restriction on the use of
> the concrete C API such that it is *only* used
> when a exact type match has been found or created
> (i.e. if someone writes Py_ListNew(), then it
> is okay to use Py_ListSet
On Wed, Apr 6, 2011 at 12:05 AM, Antoine Pitrou wrote:
>
> Hello,
>
> For the record, we have 9 stable buildbots, one of which is currently
> offline: 3 Windows, 2 OS X, 3 Linux and 1 Solaris.
> Paul Moore's XP buildbot is back in the stable stable.
> (http://www.python.org/dev/buildbot/all/waterf
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
...
> #. ``__version_info__`` SHOULD be of the format returned by PEP 386's
>``parse_version()`` function.
The only reference to parse_version in PEP 386 I could find was the
setuptools implementation which is pretty odd:
>
> In other words, pa
46 matches
Mail list logo
