Re: [Python-Dev] datetime nanosecond support. list of proposals

2012-07-28 Thread Vincenzo Ampolo 
Hi all again,

I've been quite busy these days and I collected all the suggestions
about the proposal. Here is a small summary:

Christian Heimes:
two numbers:
Julian Day Number (Rata Die) 32 bit signed integer
nanoseconds in a day 64 bit signed or unsigned integer
pro:
fix 2038 bug
cons:
hard conversion to Gregorian calendar

Charles Cazabon:
use tai64/tai64n/tai64na
pro:
well defined
libraries available
cons:
?

As ways to implement the idea there are these advices:

Nick Coghlan:
define common API based on datetime
maybe use TAI
fork the pure Python version of datetime, then fork the C
implementation to make PyPI version faster, then make a PEP

Guido van Rossum:
must do:
clever backward compatibility
use fewer bits as possible
stdlib is not the right place for first implementation

Since I'm not a big expert of calendars and date representation I'm
going to study the Julian Calendar and the TAI representation.
As a first read from Wikipedia the TAI solution looks very promising.

For the ways to implement the idea I also believe that It's better to
have a pure python implementation (so It can be used on python 2.x and
distributed on PyPI) and then a Python 3.x C implementation and a PEP
submission.

I'm open to any other idea/advice. If there are other people that would
like to implement this with me, just write me a mail.

Thank you.

Best Regards,
-- 
Vincenzo Ampolo
http://vincenzo-ampolo.net
http://goshawknest.wordpress.com
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] __sizeof__ tests

2012-07-28 Thread Serhiy Storchaka 
I have a set of patches about the correct __sizeof__ implementations 
(one has already been committed (issue #15456), 13 left, 2 of them 
published (#15469 for deque and #15475 for itertools)). The most tedious 
is to write tests for them, especially paranoid tests, on which Martin 
v. Löwis insists. For not to duplicate the supporting code, I suggest 
add (move from test_sys test) three utility functions to test.support 
module (issue #15467). Also from the use of the common code will benefit 
issues #15402 (for struct) and #15424 (for array). The testing for 
cElemetTree also will be easier.


Martin remarked that this adds new features to test.support and can only 
be done in 3.4. Question to release managers. Whether this is 
acceptable, if we do these functions private (with names that begin with 
an underscore)? Or would we have to copy the supporting code in every 
test file with __sizeof__ test?


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] __sizeof__ tests

2012-07-28 Thread Chris Jerdonek 
On Sat Jul 28 10:54:24 CEST 2012, Serhiy Storchaka storchaka at gmail.com wrote:

> For not to duplicate the supporting code, I suggest
> add (move from test_sys test) three utility functions to test.support
> module (issue #15467). Also from the use of the common code will benefit
> issues #15402 (for struct) and #15424 (for array). The testing for
> cElemetTree also will be easier.
>
> Martin remarked that this adds new features to test.support and can only
> be done in 3.4. Question to release managers. Whether this is
> acceptable, if we do these functions private (with names that begin with
> an underscore)? Or would we have to copy the supporting code in every
> test file with __sizeof__ test?

This is nearly the same as the question I asked below about feature
freeze (or that I was trying to ask), to which I thought I received an
answer different from the one stated above:

"(2) When adding new tests (e.g. in the course of fixing a bug or
increasing test coverage), are we allowed to refactor other tests so
that supporting test code can be shared?  Or should the tests be added
in a less DRY fashion and refactored only after the branch goes back
to pre-alpha?"

http://mail.python.org/pipermail/python-dev/2012-July/121137.html

I don't feel test.support should be held to the same standard as the
public modules based in part on the documentation note below:

"Note: test.support is not a public module. It is documented here to
help Python developers write tests. The API of this module is subject
to change without backwards compatibility concerns between releases."

http://docs.python.org/dev/library/test.html#module-test.support

I think it benefits us to have a test support API that we can change
at any time.  This lets us improve the quality and maintainability of
our tests (e.g. by making them more DRY) with fewer obstacles.
Otherwise, we are creating barriers for ourselves to increasing code
coverage of the code that we really want to keep unchanged.

--Chris
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] feature freeze questions

2012-07-28 Thread Chris Jerdonek 
On Wed, Jul 25, 2012 at 4:29 PM, Benjamin Peterson  wrote:
>> (2) When adding new tests (e.g. in the course of fixing a bug or
>> increasing test coverage), are we allowed to refactor other tests so
>> that supporting test code can be shared?  Or should the tests be added
>> in a less DRY fashion and refactored only after the branch goes back
>> to pre-alpha?
>
> You can do basically anything you want to tests just as long as you
> don't make them less stable.

Also, this response seems somewhat at odds to the response I got to a
patch that refactors part of regrest, fixes some bugs in it, and adds
its first unit tests (in particular, increasing code coverage):

http://bugs.python.org/issue15302

The regrtest module only affects tests (which I would think qualifies
it as "tests"), and this is borne out by the following documentation
note (which is essentially the same as the note for test.support):

"Note: The test package is meant for internal use by Python only. It
is documented for the benefit of the core developers of Python. Any
use of this package outside of Python’s standard library is
discouraged as code mentioned here can change or be removed without
notice between releases of Python.

"The test package contains all regression tests for Python as well as
the modules test.support and test.regrtest. test.support is used to
enhance your tests while test.regrtest drives the testing suite."

(from http://docs.python.org/dev/library/test.html#module-test )

--Chris
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] __sizeof__ tests

2012-07-28 Thread Nick Coghlan 
On Sat, Jul 28, 2012 at 6:54 PM, Serhiy Storchaka  wrote:
> I have a set of patches about the correct __sizeof__ implementations (one
> has already been committed (issue #15456), 13 left, 2 of them published
> (#15469 for deque and #15475 for itertools)). The most tedious is to write
> tests for them, especially paranoid tests, on which Martin v. Löwis insists.
> For not to duplicate the supporting code, I suggest add (move from test_sys
> test) three utility functions to test.support module (issue #15467). Also
> from the use of the common code will benefit issues #15402 (for struct) and
> #15424 (for array). The testing for cElemetTree also will be easier.
>
> Martin remarked that this adds new features to test.support and can only be
> done in 3.4. Question to release managers. Whether this is acceptable, if we
> do these functions private (with names that begin with an underscore)? Or
> would we have to copy the supporting code in every test file with __sizeof__
> test?

No, Martin is incorrect on this one. test.support is strictly our turf
and not covered by the normal standard library rules - the only reason
it is documented at all is because *we* want docs for it so people
writing tests don't reinvent too many wheels. Since we reserve the
right to delete stuff without notice, we can certainly add new stuff.

>From the top of the "test" package docs:
=
The test package is meant for internal use by Python only. It is
documented for the benefit of the core developers of Python. Any use
of this package outside of Python’s standard library is discouraged as
code mentioned here can change or be removed without notice between
releases of Python.
=

Cheers,
Nick.


-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] feature freeze questions

2012-07-28 Thread Nick Coghlan 
On Sat, Jul 28, 2012 at 8:25 PM, Chris Jerdonek
 wrote:
> Also, this response seems somewhat at odds to the response I got to a
> patch that refactors part of regrest, fixes some bugs in it, and adds
> its first unit tests (in particular, increasing code coverage):
>
> http://bugs.python.org/issue15302
>
> The regrtest module only affects tests (which I would think qualifies
> it as "tests"), and this is borne out by the following documentation
> note (which is essentially the same as the note for test.support):

Asking that #15302 be postponed is a risk judgement taking into
account "what do we have time to review before rc1?". Cleaning up the
argument parsing in regrtest is definitely a good thing to do, but
it's not an urgent fix.

A similar judgement call will be made for any test suite changes
between now and rc1: weighing up the risk of causing problems with the
release process vs having improved tests at the time of the release.
Anyone with commit rights gets to make that call, and we have three
options: yes, no, or ask the Release Manager (Georg for 3.3). Getting
to make that final call is one of the main responsibilities of the RM
(the default answer is usually "No", given that whichever of us asks
the question clearly has misgivings about the idea of including the
change).

Once we hit rc1, I expect Georg will fork the 3.3 maintenance branch,
and any code changes between then and the final release will only
happen specifically at his request (the docs will remain open to any
committer).

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] __sizeof__ tests

2012-07-28 Thread Serhiy Storchaka 

On 28.07.12 12:58, Chris Jerdonek wrote:

This is nearly the same as the question I asked below about feature
freeze (or that I was trying to ask), to which I thought I received an
answer different from the one stated above:


Thank you, Chris.


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Requesting pronouncement on PEP 0424

2012-07-28 Thread Alex Gaynor 
Hi all,

The discussion on PEP 0424 seems to have subsided (and I haven't gotten angry 
emails in a week!). So I would like to request a BDFL or BDFP pronouncement
on PEP 0424, text available here: 
http://hg.python.org/peps/file/tip/pep-0424.txt

Alex

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Requesting pronouncement on PEP 0424

2012-07-28 Thread Guido van Rossum 
I'll pronounce. Give me a few days.

On Sat, Jul 28, 2012 at 10:05 AM, Alex Gaynor  wrote:
> Hi all,
>
> The discussion on PEP 0424 seems to have subsided (and I haven't gotten angry
> emails in a week!). So I would like to request a BDFL or BDFP pronouncement
> on PEP 0424, text available here: 
> http://hg.python.org/peps/file/tip/pep-0424.txt

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] feature freeze questions

2012-07-28 Thread Chris Jerdonek 
On Sat, Jul 28, 2012 at 6:21 AM, Nick Coghlan  wrote:
> On Sat, Jul 28, 2012 at 8:25 PM, Chris Jerdonek
>  wrote:
>> Also, this response seems somewhat at odds to the response I got to a
>> patch that refactors part of regrest, fixes some bugs in it, and adds
>> its first unit tests (in particular, increasing code coverage):
>>
>> http://bugs.python.org/issue15302
>
> Asking that #15302 be postponed is a risk judgement taking into
> account "what do we have time to review before rc1?". Cleaning up the
> argument parsing in regrtest is definitely a good thing to do, but
> it's not an urgent fix.
>
> A similar judgement call will be made for any test suite changes
> between now and rc1: weighing up the risk of causing problems with the
> release process vs having improved tests at the time of the release.

I guess I'm still not clear on the restrictions to making changes to
test-related code -- whether these restrictions apply just to the RC
phase, or also to the bugfix releases in maintenance branches.

In a previous e-mail, you said in response to the question:

> > Martin remarked that this adds new features to test.support and can
> > only be done in 3.4. Question to release managers. Whether this is
> > acceptable, if we do these functions private (with names that begin
> > with an underscore)? Or would we have to copy the supporting code in
> > every test file with __sizeof__ test?
>
> No, Martin is incorrect on this one. test.support is strictly our turf
> and not covered by the normal standard library rules - the only reason
> it is documented at all is because *we* want docs for it so people
> writing tests don't reinvent too many wheels. Since we reserve the
> right to delete stuff without notice, we can certainly add new stuff.

(from http://mail.python.org/pipermail/python-dev/2012-July/121162.html )

This e-mail is also relevant:

> The extra restrictions during RC are more about not doing things that
> might force the release to be postponed while a broken change gets
> unwound. During normal maintenance, we have a bit more time to recover
> based on buildbot failures or post-checkin review.

http://mail.python.org/pipermail/python-dev/2012-July/121142.html

But with regard to the regrtest changes in issue 15302, which do
fix three bugs (it was marked as a superseder to three issues), Georg commented:

> Please leave this for Python 3.4 -- it is not a bugfix.

It seems like the following would be a very common scenario:

We have bug fixes that could be made to the Python 3.3 maintenance
branch (for example), but the bug fixes are written in a way that
change or otherwise enhance existing test code like test.support or
regrtest.  If enhancements to our test support code can only go into
Python 3.4, then it seems like we are creating an incentive to write
lower quality test code (e.g. avoiding refactoring, and encouraging
practices like cut and paste) -- even for our next minor version.

This creates a trade-off that it doesn't seem like we need to have or
be imposing on ourselves: between having bugs fixed in an earlier
version, and writing higher quality tests for our future versions.

There is also a possible cumulative effect: whereby not committing
test-support enhancements to maintenance branches can also prevent
future bug fixes that depend on that support code from being able to
go in those maintenance branches.

--Chris
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Requesting pronouncement on PEP 0424

2012-07-28 Thread Guido van Rossum 
Looks good to me, so accepted.

But why isn't it visible on python.org/dev/peps/ yet?

On Sat, Jul 28, 2012 at 7:37 PM, Guido van Rossum  wrote:

> I'll pronounce. Give me a few days.
>
> On Sat, Jul 28, 2012 at 10:05 AM, Alex Gaynor 
> wrote:
> > Hi all,
> >
> > The discussion on PEP 0424 seems to have subsided (and I haven't gotten
> angry
> > emails in a week!). So I would like to request a BDFL or BDFP
> pronouncement
> > on PEP 0424, text available here:
> http://hg.python.org/peps/file/tip/pep-0424.txt
>
> --
> --Guido van Rossum (python.org/~guido )
>



-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Requesting pronouncement on PEP 0424

2012-07-28 Thread Benjamin Peterson 
2012/7/28 Guido van Rossum :
> Looks good to me, so accepted.
>
> But why isn't it visible on python.org/dev/peps/ yet?

The rebuilding hook is broken.



-- 
Regards,
Benjamin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Requesting pronouncement on PEP 0424

2012-07-28 Thread Antoine Pitrou 
On Sat, 28 Jul 2012 17:05:01 + (UTC)
Alex Gaynor  wrote:

> Hi all,
> 
> The discussion on PEP 0424 seems to have subsided (and I haven't gotten angry 
> emails in a week!). So I would like to request a BDFL or BDFP pronouncement
> on PEP 0424, text available here: 
> http://hg.python.org/peps/file/tip/pep-0424.txt

"It may raise a ``TypeError`` if a 32 specific instance cannot have its
length estimated."

-> what is the consumer supposed to do in this case? Propagate the
error, or use a default value?

Regards

Antoine.


-- 
Software development and contracting: http://pro.pitrou.net


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Requesting pronouncement on PEP 0424

2012-07-28 Thread martin 

But why isn't it visible on python.org/dev/peps/ yet?


Because the build process of the PEPs broke when hg.python.org became
its own system.

I'll try to look into that tomorrow, since unfortunately nobody else  
volunteered

to fix it.

Regards,
Martin

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com