Re: [Python-Dev] Policy Decisions, Judgment Calls, and Backwards Compatibility (was Re: splitext('.cshrc'))

[Martin v. Löwis]

Grig Gheorghiu schrieb:
> Titus and I are thinking about mentoring a Google Summer of Code
> project that would use the 'buildbot try' feature: set up a bunch of
> buildbot slaves and set them up so sending them a patch will trigger a
> checkout of the latest Python svn, followed by the application of the
> patch, followed by building and running unit tests for Python,
> followed by running test suites for various projects (similar to how
> it's being done in the community buildbot farm). This will hopefully
> give us a better grasp about how good a patch is, and will make the
> process of accepting patches more smooth.
> 
> What do people think?

Sounds great! It would be even better if it could automatically
pull patches off the roundup tracker, try to apply them, and
post a message into roundup whether the patch applied and tested
successfully. To prevent spamming, it may be necessary to
explicitly release patches to buildbot (i.e. classify attachments
as non-patch, released, or verified), but that could be done
later.

Regards,
Martin

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

Re: [Python-Dev] version-specific PYTHONPATH env var

[Martin v. Löwis]

Anthony Baxter schrieb:
> What do people think about the idea of a version-specific PYTHONPATH 
> environment variable?

I agree with Guido. I normally need an application-specific PYTHONPATH,
and I do that by editing the start script adding a sys.path.append
into it (these days, Python applications often come with a tiny
start script that then imports the main functionality from a module).
Examples where I do this include buildbot, moinmoin, and roundup.
As a system's administrator, I discourage people from setting PATH,
LD_LIBRARY_PATH, PYTHONPATH, and, if possible, CLASSPATH. Instead, I
try to manage the system so that system-wide software is available
to every user without additional setup.

Regards,
Martin

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

Re: [Python-Dev] version-specific PYTHONPATH env var

[Ralf Schmitt]

On 3/9/07, Anthony Baxter <[EMAIL PROTECTED]> wrote:


What do people think about the idea of a version-specific PYTHONPATH
environment variable? Something like PYTHON25PATH or the like.
Reason I ask is that on our production systems, we have a couple of
versions of Python being used by different systems. Yes, yes, in a
perfect world they'd be all updated at the same time, sure. There's
occasionally issues with the PYTHONPATH being pointed at something
like .../lib/python2.4/site-packages or the like, and then have
issues when python2.3 or some other different version is run. If we
allowed people to optionally specify a more specific version this
problem would go away.



Few weeks ago I actually needed exactly this functionality. I worked around
it with a .pth file installed for
each version of python I'm using with the following contents:

import sys; sys.path.insert(0, os.path.expanduser("~/pylib%s.%s" %
sys.version_info[:2]))
import site, os, sys; site.addsitedir(os.path.expanduser("~/pylib%s.%s" %
sys.version_info[:2]))
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] splitext('.cshrc')

[Patrick Maupin]

On 3/8/07, Tony Nelson <[EMAIL PROTECTED]> wrote:
> At 2:16 PM -0500 3/8/07, Phillip J. Eby wrote:
> >The code in question was a type association handler that looked up loader
> >functions based on file extension.  This was specifically convenient for
> >recognizing the difference between .htaccess files and other dotfiles that
> >might appear in a web directory tree -- e.g. .htpasswd.  The proposed
> >change of splitext() would break that determination, because .htpasswd and
> >.htaccess would both be considered files with empty extensions, and would
> >be handled by the "empty extension" handler.
>
> So, ".htaccess" and "foo.htaccess" should be treated the same way?  Is that
> what Apache does?

I've never personally used "foo.htaccess", but I have had files named,
e.g. "test1.htaccess", or "backup.htaccess".  And I don't know, but I
assume a "foo.htaccess" would be an older or test version of a
.htaccess file.  So, my usecases say, "yes, they should be treated the
same."

Regards,
Pat
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] datetime module enhancements

[Christian Heimes]

Hello!

This is my first posting to the Python developer list so please forgive
me if I'm doing something wrong.

In the past few weeks I've worked a lot with dates and times. I found
several small annoyances in the datetime module. For example there was
no obvious way to cast a timedelta to an int or float. I'm proposing
some small additions to the datetime module:

>>> td = timedelta(minutes=1, seconds=7, microseconds=500)
>>> int(td)
67
>>> long(td)
67L
>>> float(td)
67.5
>>> round(td)
68.0

datetime.datetime has a method (class factory) fromtimestamp() but its
instances are missing a totimestamp() method that return the Unix
timestamp for a date (seconds since 1970-01-01 00:00:00 UTC).

Some people might miss a from and to julian day number (JDN) and
modified julian day (MJD) converter in datetime.date and
datetime.datetime. MJD is used as base in VMS and JDN, MJD and RJD are
used by astronomers. It's also very useful when one has to deal with
dates before 0 and converting dates between foreign calendars.

>From http://www.slac.stanford.edu/~rkj/crazytime.txt
---
November 17, 1858 is the base of the Modified Julian Day system.

The original Julian Day (JD) is used by astronomers and expressed in
days since noon January 1, 4713 B.C.  This measure of time was
introduced by Joseph Scaliger in the 16th century.  It is named in
honor of his father, Julius Caesar Scaliger (note that this Julian Day
is different from the Julian calendar named for the Roman Emperor
Julius Caesar!).
---

http://en.wikipedia.org/wiki/Julian_Day

I'm willing to implement the features myself but I need a mentor who
helps me to correct my code and applies it to the Python svn repository.

A patch for timedelta is already available at
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1665292&group_id=5470

Comments?

Christian

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

Re: [Python-Dev] Policy Decisions, Judgment Calls, and Backwards Compatibility (was Re: splitext('.cshrc'))

[Phillip J. Eby]

At 08:57 AM 3/9/2007 +0100, Martin v. Löwis wrote:
>In the case that triggered the discussion, the change implemented
>was not an incompatible change, because the new implementation still
>met the old specification (which, of course, was underspecified).

No, it wasn't, actually.  Read the doc strings, which state exactly what 
the code does.


Windows:

 >>> import os
 >>> help(os.path.splitext)
Help on function splitext in module ntpath:

splitext(p)
 Split the extension from a pathname.

 Extension is everything from the last dot to the end.
 Return (root, ext), either part may be empty.


Posix:

 >>> import os
 >>> help(os.path.splitext)
Help on function splitext in module posixpath:

splitext(p)
 Split the extension from a pathname.  Extension is everything from the
 last dot to the end.  Returns "(root, ext)", either part may be empty.

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

Re: [Python-Dev] datetime module enhancements

[skip]

Christian> I'm proposing some small additions to the datetime module:

>>> td = timedelta(minutes=1, seconds=7, microseconds=500)
>>> int(td)
67
>>> long(td)
67L
>>> float(td)
67.5
>>> round(td)
68.0

Casting to the number of seconds seems a bit arbitrary.  Why not cast to the
number of days or number of microseconds?  If you allow interpretation of
timedeltas as int, long or float I'd argue that round not be included.
Instead, just round the output of float.

Christian> datetime.datetime has a method (class factory)
Christian> fromtimestamp() but its instances are missing a totimestamp()
Christian> method that return the Unix timestamp for a date (seconds
Christian> since 1970-01-01 00:00:00 UTC).

The range of datetime objects far exceeds that of the current Unix
timestamp.  Given that the range of current (32-bit) Unix timestamps is
approximately 1970 to 2038, What would the output of this be?

dt = datetime.datetime(3000, 1, 1, 0, 0, 0)
print dt.totimestamp()
dt = datetime.datetime(1900, 1, 1, 0, 0, 0)
print dt.totimestamp()

Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] datetime module enhancements

[Guido van Rossum]

On 3/9/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Christian> I'm proposing some small additions to the datetime module:
>
> >>> td = timedelta(minutes=1, seconds=7, microseconds=500)
> >>> int(td)
> 67
> >>> long(td)
> 67L
> >>> float(td)
> 67.5
> >>> round(td)
> 68.0
>
> Casting to the number of seconds seems a bit arbitrary.  Why not cast to the
> number of days or number of microseconds?

Because seconds are what's used everywhere else when Python represents
time as a number (time.time(), time.sleep(), select, socket timeout,
etc.)

> If you allow interpretation of
> timedeltas as int, long or float I'd argue that round not be included.
> Instead, just round the output of float.
>
> Christian> datetime.datetime has a method (class factory)
> Christian> fromtimestamp() but its instances are missing a totimestamp()
> Christian> method that return the Unix timestamp for a date (seconds
> Christian> since 1970-01-01 00:00:00 UTC).
>
> The range of datetime objects far exceeds that of the current Unix
> timestamp.  Given that the range of current (32-bit) Unix timestamps is
> approximately 1970 to 2038, What would the output of this be?
>
> dt = datetime.datetime(3000, 1, 1, 0, 0, 0)
> print dt.totimestamp()
> dt = datetime.datetime(1900, 1, 1, 0, 0, 0)
> print dt.totimestamp()

If you extend the range to 64 bits there's no problem: the first
should print 3250368, the second -2208988800.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] datetime module enhancements

[BJörn Lindqvist]

On 3/9/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 3/9/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > The range of datetime objects far exceeds that of the current Unix
> > timestamp.  Given that the range of current (32-bit) Unix timestamps is
> > approximately 1970 to 2038, What would the output of this be?
> >
> > dt = datetime.datetime(3000, 1, 1, 0, 0, 0)
> > print dt.totimestamp()
> > dt = datetime.datetime(1900, 1, 1, 0, 0, 0)
> > print dt.totimestamp()
>
> If you extend the range to 64 bits there's no problem: the first
> should print 3250368, the second -2208988800.

I think it should be a ValueError, given that the programmer is very
likely to further use the returned timestamp to for example insert
stuff in a database. Unix timestamps are not unambiguously defined for
any years other than 1970 to 2038 imho.

-- 
mvh Björn
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] datetime module enhancements

[Guido van Rossum]

On 3/9/07, BJörn Lindqvist <[EMAIL PROTECTED]> wrote:
> On 3/9/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > On 3/9/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > > The range of datetime objects far exceeds that of the current Unix
> > > timestamp.  Given that the range of current (32-bit) Unix timestamps is
> > > approximately 1970 to 2038, What would the output of this be?
> > >
> > > dt = datetime.datetime(3000, 1, 1, 0, 0, 0)
> > > print dt.totimestamp()
> > > dt = datetime.datetime(1900, 1, 1, 0, 0, 0)
> > > print dt.totimestamp()
> >
> > If you extend the range to 64 bits there's no problem: the first
> > should print 3250368, the second -2208988800.
>
> I think it should be a ValueError, given that the programmer is very
> likely to further use the returned timestamp to for example insert
> stuff in a database. Unix timestamps are not unambiguously defined for
> any years other than 1970 to 2038 imho.

But they will be. And they already are on some platforms. The database
should raise an OverflowError if a timestamp is out of range, but it
would be unpythonic to limit those outcomes to 32 bits.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] datetime module enhancements

[BJörn Lindqvist]

On 3/9/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 3/9/07, BJörn Lindqvist <[EMAIL PROTECTED]> wrote:
> > On 3/9/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > > On 3/9/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > > > The range of datetime objects far exceeds that of the current Unix
> > > > timestamp.  Given that the range of current (32-bit) Unix timestamps is
> > > > approximately 1970 to 2038, What would the output of this be?
> > > >
> > > > dt = datetime.datetime(3000, 1, 1, 0, 0, 0)
> > > > print dt.totimestamp()
> > > > dt = datetime.datetime(1900, 1, 1, 0, 0, 0)
> > > > print dt.totimestamp()
> > >
> > > If you extend the range to 64 bits there's no problem: the first
> > > should print 3250368, the second -2208988800.
> >
> > I think it should be a ValueError, given that the programmer is very
> > likely to further use the returned timestamp to for example insert
> > stuff in a database. Unix timestamps are not unambiguously defined for
> > any years other than 1970 to 2038 imho.
>
> But they will be. And they already are on some platforms. The database
> should raise an OverflowError if a timestamp is out of range, but it
> would be unpythonic to limit those outcomes to 32 bits.

Then I guess datetime.fromtimestamp() also should be fixed?:

>>> datetime.fromtimestamp(-1)
Traceback (most recent call last):
  File "", line 1, in 
ValueError: timestamp out of range for platform localtime()/gmtime() function
>>> datetime.fromtimestamp(-0.5)
Traceback (most recent call last):
  File "", line 1, in 
ValueError: microsecond must be in 0..99
>>> datetime.fromtimestamp(99)
Traceback (most recent call last):
  File "", line 1, in 
ValueError: timestamp out of range for platform time_t

Would be nice if datetime.fromtimestamp(dt.totimestamp()) == dt worked
for all datetimes.

-- 
mvh Björn
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] datetime module enhancements

[Christian Heimes]

BJörn Lindqvist schrieb:
> I think it should be a ValueError, given that the programmer is very
> likely to further use the returned timestamp to for example insert
> stuff in a database. Unix timestamps are not unambiguously defined for
> any years other than 1970 to 2038 imho.

IIRC the unix timestamp was originally definied as *signed* int with 32bit.

http://en.wikipedia.org/wiki/Time_t
---
Unix and POSIX-compliant systems implement the time_t type as a signed
integer (typically 32 or 64 bits wide) which represents the number of
seconds since the start of the Unix epoch: midnight UTC of January 1,
1970 (not counting leap seconds). Some systems support negative time
values, while others do not.
---

But you made a good point! What do you think about
datetime.totimestamp(asLong=False)? The method would raise a ValueError
or OverflowError if the value is > sys.maxint or < -(sys.maxint-1).

Christian

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

Re: [Python-Dev] datetime module enhancements

[Christian Heimes]

BJörn Lindqvist schrieb:
> Then I guess datetime.fromtimestamp() also should be fixed?:
[...]
> Would be nice if datetime.fromtimestamp(dt.totimestamp()) == dt worked
> for all datetimes.

Yeah great idea but I'm not sure if I'm up to the task. I'm not that
familiar with C level date and time libraries.

Christian

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

Re: [Python-Dev] Policy Decisions, Judgment Calls, and Backwards Compatibility (was Re: splitext('.cshrc'))

[Martin v. Löwis]

Phillip J. Eby schrieb:
> At 08:57 AM 3/9/2007 +0100, Martin v. Löwis wrote:
>> In the case that triggered the discussion, the change implemented
>> was not an incompatible change, because the new implementation still
>> met the old specification (which, of course, was underspecified).
> 
> No, it wasn't, actually.  Read the doc strings, which state exactly what 
> the code does.

The doc strings were precise, yes. The documentation (Doc/lib) was
underspecified and allowed for both interpretations:

splitext(path)
Split the pathname path into a pair (root, ext) such that root + ext == 
path, and ext is empty or begins with a period and contains at most one 
period.

Regards,
Martin

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

[Python-Dev] Introduction

[Žiga Seilnacht]

Hi all!

I have just accepted an invitation to become a Python
developer, so I feel obliged to introduce myself.

My name is Žiga Seilnacht. I'm currently studying civil
engineering at the University of Ljubljana, Slovenia.

I started learning Python approximately two years ago, as
my first computer language. I got involved with Python
development a year ago, on the last bug day. My experience
was much more pleasant than Michael Foord's; Georg checked
in my first patch in under 30 minutes, and he had to fix
my tests first :).

As a Python developer, I will continue to focus on bug
triage, bug fixing and reviewing patches; I don't feel
I'm qualified for language design.

I'm occasionally lurking on various Python related IRC
channels under the nick zseil. Feel free to contact me!

Regards,
Ziga



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

Re: [Python-Dev] datetime module enhancements

[Collin Winter]

On the subject of datetime enhancements, I came across an SF patch
(#1673403) the other day that proposed making it possible to compare
date and datetime objects. Quoting from the patch summary:

"""
Comparing a date to a datetime currently throws an exception. This makes no
sense. In what way is:

datetime(2006, 1, 1, 0, 0, 0) < date(2007, 1, 1)

not a perfectly reasonable and well-defined comparison? Throwing an
exception here violates the "Principle of Least Surprise" to a considerable
degree.

Obviously some slight ambiguity arises if the date and the datetime differ
only in the time part. There are two sensible responses in this situation
that I can see:

Treat dates as if they have a time-part of midnight. This is my preferred
solution, and it is already what the datetime module does, for example,
when subtracting two dates.

Treat dates as if they refer to the entire day, i.e. if the date and
datetime differ only in the time part then they are equal. This is
consistent but becomes confusing in other situations such as when
subtracting dates.
"""

Any thoughts on this?

Collin Winter
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] datetime module enhancements

[Martin v. Löwis]

Christian Heimes schrieb:
> BJörn Lindqvist schrieb:
>> I think it should be a ValueError, given that the programmer is very
>> likely to further use the returned timestamp to for example insert
>> stuff in a database. Unix timestamps are not unambiguously defined for
>> any years other than 1970 to 2038 imho.
> 
> IIRC the unix timestamp was originally definied as *signed* int with 32bit.

"Unix" time stamps where never defined as being 32bit. That is just an
implementation detail. time_t was defined as an int, in second since 
1970, and that is all what was defined. Whether or not an int is 32bits
depends on the hardware (and the compiler); this was never part of Unix.

Regards,
Martin

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

Re: [Python-Dev] Introduction

[Guido van Rossum]

On 3/9/07, Žiga Seilnacht <[EMAIL PROTECTED]> wrote:
> Hi all!
>
> I have just accepted an invitation to become a Python
> developer, so I feel obliged to introduce myself.


Nice to meet you, Ziga!

> My name is Žiga Seilnacht. I'm currently studying civil
> engineering at the University of Ljubljana, Slovenia.
>
> I started learning Python approximately two years ago, as
> my first computer language. I got involved with Python
> development a year ago, on the last bug day. My experience
> was much more pleasant than Michael Foord's; Georg checked
> in my first patch in under 30 minutes, and he had to fix
> my tests first :).
>
> As a Python developer, I will continue to focus on bug
> triage, bug fixing and reviewing patches; I don't feel
> I'm qualified for language design.

Yet. :-)

> I'm occasionally lurking on various Python related IRC
> channels under the nick zseil. Feel free to contact me!
>
> Regards,
> Ziga

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] datetime module enhancements

[Martin v. Löwis]

BJörn Lindqvist schrieb:

>> If you extend the range to 64 bits there's no problem: the first
>> should print 3250368, the second -2208988800.
> 
> I think it should be a ValueError, given that the programmer is very
> likely to further use the returned timestamp to for example insert
> stuff in a database. 

Then this operation (the insertion into a database) should give a
ValueError. Python conceptually has only a single integer type, and
that has no range limitation.

Of course, if "conversion to time_t" was an operation in datetime,
than this should limit it in the range of time_t (which may or
may not have 32 bits).

> Unix timestamps are not unambiguously defined for
> any years other than 1970 to 2038 imho.

As others have said: this is simply not true. It depends on
the hardware, Unix explicitly, deliberately, leaves that open
to the specific operating system implementation. On a 36-bit
hardware, the range will be different.

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Introduction

[Brett Cannon]

On 3/9/07, Žiga Seilnacht <[EMAIL PROTECTED]> wrote:
> Hi all!
>
> I have just accepted an invitation to become a Python
> developer, so I feel obliged to introduce myself.
>
> My name is Žiga Seilnacht. I'm currently studying civil
> engineering at the University of Ljubljana, Slovenia.
>

Welcome aboard!

> I started learning Python approximately two years ago, as
> my first computer language. I got involved with Python
> development a year ago, on the last bug day. My experience
> was much more pleasant than Michael Foord's; Georg checked
> in my first patch in under 30 minutes, and he had to fix
> my tests first :).
>
> As a Python developer, I will continue to focus on bug
> triage, bug fixing and reviewing patches; I don't feel
> I'm qualified for language design.
>

Don't worry about it.  You can still express your opinion as a user of
Python.  Language design is more about getting hit with some
inspiration for something than being "qualified" for it.

-Brett
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Introduction

[Raymond Hettinger]

[Žiga Seilnacht]
>I have just accepted an invitation to become a Python
>developer, so I feel obliged to introduce myself.

Welcome aboard.


Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] datetime module enhancements

[Martin v. Löwis]

Collin Winter schrieb:
> 
> Any thoughts on this?

There are know problems comparing durations (e.g. is 30 days more
or less than a month?). For time stamps, there is no issue. For
calender dates, there are again problems, in particular with time
zones.

What I don't know (because I never used it) is whether the datetime
module implements time stamps. If it does (i.e. no durations,
no time zones, no issues with leap seconds), then supporting a
total order seems reasonable.

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Introduction

[Georg Brandl]

Žiga Seilnacht schrieb:
> Hi all!
> 
> I have just accepted an invitation to become a Python
> developer, so I feel obliged to introduce myself.

Welcome from me too!

I was always pleased to see your name in some SF issue
because it generally meant to look for high-quality comment or
patch next to it :)

cheers,
Georg

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

Re: [Python-Dev] datetime module enhancements

[Brett Cannon]

On 3/9/07, Collin Winter <[EMAIL PROTECTED]> wrote:
> On the subject of datetime enhancements, I came across an SF patch
> (#1673403) the other day that proposed making it possible to compare
> date and datetime objects. Quoting from the patch summary:
>
> """
> Comparing a date to a datetime currently throws an exception. This makes no
> sense. In what way is:
>
> datetime(2006, 1, 1, 0, 0, 0) < date(2007, 1, 1)
>
> not a perfectly reasonable and well-defined comparison? Throwing an
> exception here violates the "Principle of Least Surprise" to a considerable
> degree.
>
> Obviously some slight ambiguity arises if the date and the datetime differ
> only in the time part. There are two sensible responses in this situation
> that I can see:
>
> Treat dates as if they have a time-part of midnight. This is my preferred
> solution, and it is already what the datetime module does, for example,
> when subtracting two dates.
>
> Treat dates as if they refer to the entire day, i.e. if the date and
> datetime differ only in the time part then they are equal. This is
> consistent but becomes confusing in other situations such as when
> subtracting dates.
> """
>
> Any thoughts on this?
>

I personally like the current solution.  The proposal to just assume
midnight goes against EIBTI in my mind.

-Brett
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] r53997 - in python/trunk: Lib/test/crashers/modify_dict_attr.py Lib/test/test_descr.py Objects/typeobject.c

[Armin Rigo]

Hi Jeremy,

On Tue, Feb 27, 2007 at 07:29:50PM +0100, jeremy.hylton wrote:
> Removed:
>python/trunk/Lib/test/crashers/modify_dict_attr.py
> Modified:
>python/trunk/Lib/test/test_descr.py
>python/trunk/Objects/typeobject.c
> Log:
> Add checking for a number of metaclass error conditions.

This check-in looks highly suspicious to me.  It doesn't solve the
problem it set out to solve, which is the modify_dict_attr crasher - see
the slightly modified modify_dict_attr that I re-checked in
(Lib/test/crashers/).  Instead it adds more of the obscure undocumented
rules about what kind of inheritence is allowed or not.  We already have
cases like:

class X(str): pass
class Y(str): pass
class Z(X, Y): pass
   
which are forbidden for no user-discernable reason.  I don't think that
forbidding:

class X(Y, type): pass

is going to help clarity there.

The problem with modify_dict_attr is at a different level; if needed I
can elaborate on the following comment from the SF tracker:

"""A proposed fix [for modify_dict_attr]: the __dict__ descriptor of
user-defined classes should verify if there is another __dict__
descriptor along the solid path of the type (i.e. following "tp_base"
pointers).  If so, it should delegate to it."""


A bientot,

Armin.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] buildbot warnings in g4 osx.4 trunk

[Collin Winter]

(Resending to python-dev instead of python-checkins)

Any objections to applying something like the following to address the
recent spate of buildbot failures in test_posixpath:test_islink?

Index: Lib/test/test_posixpath.py
--- Lib/test/test_posixpath.py  (revision 54248)
+++ Lib/test/test_posixpath.py  (working copy)
@@ -150,6 +150,11 @@
os.remove(test_support.TESTFN)

def test_islink(self):
+try:
+os.remove(test_support.TESTFN + "2")
+except os.error:
+pass
+
self.assertIs(posixpath.islink(test_support.TESTFN + "1"), False)
f = open(test_support.TESTFN + "1", "wb")
try:

Collin Winter

On 3/9/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> The Buildbot has detected a new failure of g4 osx.4 trunk.
> Full details are available at:
>  http://www.python.org/dev/buildbot/all/g4%2520osx.4%2520trunk/builds/1814
>
> Buildbot URL: http://www.python.org/dev/buildbot/all/
>
> Build Reason:
> Build Source Stamp: [branch trunk] HEAD
> Blamelist: collin.winter,thomas.heller
>
> Build had warnings: warnings test
>
> Excerpt from the test logfile:
> 1 test failed:
> test_posixpath
>
> make: *** [buildbottest] Error 1
>
> sincerely,
>  -The Buildbot
>
> ___
> Python-checkins mailing list
> [EMAIL PROTECTED]
> http://mail.python.org/mailman/listinfo/python-checkins
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Policy Decisions, Judgment Calls, and Backwards Compatibility (was Re: splitext('.cshrc'))

[Phillip J. Eby]

At 07:18 PM 3/9/2007 +0100, Martin v. Löwis wrote:
>Phillip J. Eby schrieb:
> > At 08:57 AM 3/9/2007 +0100, Martin v. Löwis wrote:
> >> In the case that triggered the discussion, the change implemented
> >> was not an incompatible change, because the new implementation still
> >> met the old specification (which, of course, was underspecified).
> >
> > No, it wasn't, actually.  Read the doc strings, which state exactly what
> > the code does.
>
>The doc strings were precise, yes. The documentation (Doc/lib) was
>underspecified and allowed for both interpretations:
>
>splitext(path)
>Split the pathname path into a pair (root, ext) such that root + ext ==
>path, and ext is empty or begins with a period and contains at most one
>period.

I'm just pointing out that anyone who reads *all* the documentation would 
reasonably conclude that the more specific of the two pieces is a reliable 
description of the behavior.

Therefore, this is a change to documented behavior, and can't be considered 
a bug fix.

I agree 100% with the people who think splitext() should arguably have had 
the new proposed behavior from the beginning.

However, I also agree 100% with Glyph that it's ridiculous that we should 
even have to be having this argument about changing something that's been 
like this for about a *decade* and can reasonably be considered to not be a 
bug, given that its detailed behavior is clearly documented in the 
docstrings.  Where were all these "10 Unix programmers" for the last ten years?

Obviously they've been writing their own replacement for splitext(), if and 
when they needed one -- or else the normal use cases for splitext either 
aren't dotfile-sensitive, or are *conducive to the existing 
implementation*.  In other words, one of four cases apply for existing code:

1. Old code uses its own fucntion - change has no effect

2. Old code uses splitext, but never has and never will touch dotfiles - 
change has no effect

3. Old code uses splitext, and has never touched dotfiles (otherwise it 
would have been changed to not use splitext!) but *might*, *possibly*, 
touch one at some point in the future - change *might* fix a latent bug in 
such code, but clearly it's unlikely

4. Old code uses splitext, does touch dotfiles, *likes it that way* - 
change breaks code.  (A small, but definitely non-empty group.)

So, ignoring the cases where the change makes no difference, this change will:

1. DEFINITELY break some code
2. MAYBE "fix" some code that hasn't actually broken before

I don't see how a hypothetical fix for one small group justifies definitely 
breaking the code of some other small group.

The only group the change benefits is people writing *new* code -- so give 
them a new function.

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

Re: [Python-Dev] datetime module enhancements

[Robert Brewer]

Brett Cannon wrote:
> On 3/9/07, Collin Winter <[EMAIL PROTECTED]> wrote:
> > On the subject of datetime enhancements, I came across an SF patch
> > (#1673403) the other day that proposed making it possible to compare
> > date and datetime objects...
> 
> I personally like the current solution.  The proposal to just assume
> midnight goes against EIBTI in my mind.

Yeah, but the current solution goes against, um, APBP*. Not in my mind,
but in my code. Repeatedly. I can't count how many times I've written
code like:

if created > fdate:

when I "should" have written:

if isinstance(created, datetime.date):
date_version_of_created = created
else:
date_version_of_created = created.date()
if date_version_of_created > fdate:

But it gets better, because:

>>> isinstance(datetime.datetime(x, y, z), datetime.date)
True

So the above won't work, you must remember to reverse the if/else:

if isinstance(created, datetime.datetime):
date_version_of_created = created.date()
else:
date_version_of_created = created
if date_version_of_created > fdate:

That's at least one too many "must remembers" for dumb (and busy!) ol'
me. EIBTI until it's a PITA.

Is an implicit time of 0 really so surprising? It doesn't seem to be
surprising for the datetime constructor:

>>> datetime.datetime(2007, 3, 9)
datetime.datetime(2007, 3, 9, 0, 0)

Why should it be surprising for comparisons?


Robert Brewer
System Architect
Amor Ministries
[EMAIL PROTECTED]

* APBP = "Although, practicality beats purity"
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] datetime module enhancements

[Collin Winter]

On 3/9/07, Collin Winter <[EMAIL PROTECTED]> wrote:
> On the subject of datetime enhancements, I came across an SF patch
> (#1673403) the other day that proposed making it possible to compare
> date and datetime objects. Quoting from the patch summary:
>
> """
> Comparing a date to a datetime currently throws an exception. This makes no
> sense. In what way is:
>
> datetime(2006, 1, 1, 0, 0, 0) < date(2007, 1, 1)
>
> not a perfectly reasonable and well-defined comparison? Throwing an
> exception here violates the "Principle of Least Surprise" to a considerable
> degree.
>
> Obviously some slight ambiguity arises if the date and the datetime differ
> only in the time part. There are two sensible responses in this situation
> that I can see:
>
> Treat dates as if they have a time-part of midnight. This is my preferred
> solution, and it is already what the datetime module does, for example,
> when subtracting two dates.
>
> Treat dates as if they refer to the entire day, i.e. if the date and
> datetime differ only in the time part then they are equal. This is
> consistent but becomes confusing in other situations such as when
> subtracting dates.
> """
>
> Any thoughts on this?

One solution that just occurred to me -- and that skirts the issue of
choosing an interpretation -- is that, when comparing date and
datetime objects, the datetime's .date() method is called and the
result of that call is compared to the original date. That is,

datetime_obj < date_obj

is implicitly equivalent to

datetime_obj.date() < date_obj

Seems a ready-made use case for that method.

Collin Winter
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] datetime module enhancements

[Jon Ribbens]

"\"Martin v. Löwis\"" <[EMAIL PROTECTED]> wrote:
> There are know problems comparing durations (e.g. is 30 days more
> or less than a month?). For time stamps, there is no issue. For
> calender dates, there are again problems, in particular with time
> zones.

Python durations (datetime.timedelta) do not support the concept of
"months", so that's not an issue. The timedelta type only supports
durations that are a fixed number of seconds.

I don't see what the issue with time zones would be? Surely you just
convert to the same time zone and then compare?

> What I don't know (because I never used it) is whether the datetime
> module implements time stamps. If it does (i.e. no durations,
> no time zones, no issues with leap seconds), then supporting a
> total order seems reasonable.

It supports converting *from* timestamps, but not *to* timestamps,
which is the subject of a feature request I submitted the other day
(1673409) ;-)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] datetime module enhancements

[Jon Ribbens]

Brett Cannon <[EMAIL PROTECTED]> wrote:
> > Treat dates as if they have a time-part of midnight. This is my preferred
> > solution, and it is already what the datetime module does, for example,
> > when subtracting two dates.
> 
> I personally like the current solution.  The proposal to just assume
> midnight goes against EIBTI in my mind.

Not in mine. The comparison of a date with a datetime throwing
an exception is astonishing in my mind.

The problem is, if you don't define a 'date' as I suggest (i.e.
midnight at the start of the day in question), then what *does*
a 'date' represent?

If you want the answer to be "an unknown time on that day" then
you need to alter the datetime module so that subtracting one
date from another throws an exception.

If you want the answer to be "the entire of that day" then you need
to alter the datetime module so that, e.g. subtracting 2007-03-08
from 2007-03-09 does not return "one day" as currently, but returns
"zero days" instead (since of course there is no time between the end
of one day and the start of the next day).

Obviously both of those alternatives are ludicrous (not to mention
they would break backwards-compatibility), so I would suggest the
only logical solution is to make the change I proposed ;-)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] datetime module enhancements

[Steven Bethard]

On 3/9/07, Collin Winter <[EMAIL PROTECTED]> wrote:
> One solution that just occurred to me -- and that skirts the issue of
> choosing an interpretation -- is that, when comparing date and
> datetime objects, the datetime's .date() method is called and the
> result of that call is compared to the original date. That is,
>
> datetime_obj < date_obj
>
> is implicitly equivalent to
>
> datetime_obj.date() < date_obj

Using the .date() is fine when the year/month/day doesn't match.  So
the following are fine::
datetime.datetime(2005, 1, 1, 0, 0, 0) < datetime.date(2006, 1, 1)
datetime.datetime(2007, 1, 1, 0, 0, 0) > datetime.date(2006, 1, 1)
It's *not* okay to say that a date() is less than, greater than or
equal to a datetime() if the year/month/day *does* match.  The correct
temporal relation is During, but Python doesn't have a During
operator. During is not the same as less-than, greater-than or
equal-to, so all of these should be False::
datetime.datetime(2006, 1, 1, 0, 0, 0)  < datetime.date(2006, 1, 1)
datetime.datetime(2006, 1, 1, 0, 0, 0)  > datetime.date(2006, 1, 1)
datetime.datetime(2006, 1, 1, 0, 0, 0)  == datetime.date(2006, 1, 1)
That is, the datetime() is not less than, greater than or equal to the
corresponding date().

Some discussion of these kinds of issues is here:
http://citeseer.ist.psu.edu/allen94actions.html
The essence is that in order to properly compare intervals, you need
the Meets, Overlaps, Starts, During and Finishes operators in addition
to the Before (<) and Simulaneous (=) operators.

So, let's not conflate Before, After or Simultaneous with the other
relations -- if it's not strictly Before (<), After (>) or
Simultaneous (=), we can just say so by returning False.

(I believe these semantics would be just fine for both of the examples
offered so far, but let me know if you think that's not true.)

STeVe
-- 
I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a
tiny blip on the distant coast of sanity.
--- Bucky Katt, Get Fuzzy
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] datetime module enhancements

[Collin Winter]

On 3/9/07, Steven Bethard <[EMAIL PROTECTED]> wrote:
> On 3/9/07, Collin Winter <[EMAIL PROTECTED]> wrote:
> > One solution that just occurred to me -- and that skirts the issue of
> > choosing an interpretation -- is that, when comparing date and
> > datetime objects, the datetime's .date() method is called and the
> > result of that call is compared to the original date. That is,
> >
> > datetime_obj < date_obj
> >
> > is implicitly equivalent to
> >
> > datetime_obj.date() < date_obj
>
> Using the .date() is fine when the year/month/day doesn't match.  So
> the following are fine::
> datetime.datetime(2005, 1, 1, 0, 0, 0) < datetime.date(2006, 1, 1)
> datetime.datetime(2007, 1, 1, 0, 0, 0) > datetime.date(2006, 1, 1)
> It's *not* okay to say that a date() is less than, greater than or
> equal to a datetime() if the year/month/day *does* match.  The correct
> temporal relation is During, but Python doesn't have a During
> operator. During is not the same as less-than, greater-than or
> equal-to, so all of these should be False::
> datetime.datetime(2006, 1, 1, 0, 0, 0)  < datetime.date(2006, 1, 1)
> datetime.datetime(2006, 1, 1, 0, 0, 0)  > datetime.date(2006, 1, 1)
> datetime.datetime(2006, 1, 1, 0, 0, 0)  == datetime.date(2006, 1, 1)
> That is, the datetime() is not less than, greater than or equal to the
> corresponding date().
>
> Some discussion of these kinds of issues is here:
> http://citeseer.ist.psu.edu/allen94actions.html
> The essence is that in order to properly compare intervals, you need
> the Meets, Overlaps, Starts, During and Finishes operators in addition
> to the Before (<) and Simulaneous (=) operators.
>
> So, let's not conflate Before, After or Simultaneous with the other
> relations -- if it's not strictly Before (<), After (>) or
> Simultaneous (=), we can just say so by returning False.
>
> (I believe these semantics would be just fine for both of the examples
> offered so far, but let me know if you think that's not true.)

I can't say I'm well-versed in the intricacies of date/time issues,
but what you say makes sense. This is exactly why I brought this patch
up here : )

Thanks,
Collin Winter
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] datetime module enhancements

[Georg Brandl]

Robert Brewer schrieb:
> Brett Cannon wrote:
>> On 3/9/07, Collin Winter <[EMAIL PROTECTED]> wrote:
>> > On the subject of datetime enhancements, I came across an SF patch
>> > (#1673403) the other day that proposed making it possible to compare
>> > date and datetime objects...
>> 
>> I personally like the current solution.  The proposal to just assume
>> midnight goes against EIBTI in my mind.
> 
> Yeah, but the current solution goes against, um, APBP*. Not in my mind,
> but in my code. Repeatedly. I can't count how many times I've written
> code like:
> 
> if created > fdate:
> 
> when I "should" have written:
> 
> if isinstance(created, datetime.date):
> date_version_of_created = created
> else:
> date_version_of_created = created.date()
> if date_version_of_created > fdate:
> 
> But it gets better, because:
> 
> >>> isinstance(datetime.datetime(x, y, z), datetime.date)
> True
> 
> So the above won't work, you must remember to reverse the if/else:
> 
> if isinstance(created, datetime.datetime):
> date_version_of_created = created.date()
> else:
> date_version_of_created = created
> if date_version_of_created > fdate:

Why not just give date objects a date() method that returns self?
That way you can write

if created.date() > fdate:

Georg

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

Re: [Python-Dev] datetime module enhancements

[Phillip J. Eby]

At 09:20 PM 3/9/2007 +, Jon Ribbens wrote:
>If you want the answer to be "the entire of that day" then you need
>to alter the datetime module so that, e.g. subtracting 2007-03-08
>from 2007-03-09 does not return "one day" as currently, but returns
>"zero days" instead (since of course there is no time between the end
>of one day and the start of the next day).

Unless you decide that subtraction is between days' ends.  Or days' 
beginnings.  Either suffices to produce a 1-day result in that case, and is 
still consistent with viewing days as slices of time.

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

Re: [Python-Dev] datetime module enhancements

[Christian Heimes]

Collin Winter schrieb:
> I can't say I'm well-versed in the intricacies of date/time issues,
> but what you say makes sense. This is exactly why I brought this patch
> up here : )

Oh h...! Seems like I've opened a can of worms here. I only wanted to
add some minor enhancements and now it looks like the improvements and
the datetime module have to be carefully defined and PEPed.

I'm trying to summarize the discussed issues and proposals:

 * Change the underlying time_t type (Unix timestamp) to use a unsigned
64bit integer even on 32 bit operating systems.

 * Carefully define the comparison between date and datetime objects.

 * int(timedelta) and float(timedelta) returns seconds

 * Add methods to datetime to cast from/to Julian Date Number (also MJD
and RJD)

 * What about moving the C extension to _datetime so we can implement
some non time consuming extensions in Python?

 * What do you think about including PyTz in the Python core? PyTz is
really, REALLY useful when one has to deal with time zones.
http://pytz.sourceforge.net/

 * The dateutil package contains additional features which may prove as
useful: http://labix.org/python-dateutil

Christian

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

Re: [Python-Dev] Policy Decisions, Judgment Calls, and Backwards Compatibility (was Re: splitext('.cshrc'))

[Greg Ewing]

Martin v. Löwis wrote:

> splitext(path)
> Split the pathname path into a pair (root, ext) such that root + ext == 
> path, and ext is empty or begins with a period and contains at most one 
> period.

Actually, that spec could be satisfied by a function
that *always* returned an empty string for ext...

--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] datetime module enhancements

[Greg Ewing]

Collin Winter wrote:

> Treat dates as if they have a time-part of midnight. This is my preferred
> solution, and it is already what the datetime module does, for example,
> when subtracting two dates.

Does it really? Seems to me you can pick any time of day
to be the representative time and get the same result
when subtracting two dates, as long as you pick the same
one for both dates. So it's not really assuming anything
here.

--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] datetime module enhancements

[Ka-Ping Yee]

On Sat, 10 Mar 2007, Greg Ewing wrote:
> Collin Winter wrote:
> > Treat dates as if they have a time-part of midnight. This is my preferred
> > solution, and it is already what the datetime module does, for example,
> > when subtracting two dates.
>
> Does it really? Seems to me you can pick any time of day
> to be the representative time and get the same result
> when subtracting two dates, as long as you pick the same
> one for both dates. So it's not really assuming anything
> here.

It certainly gives that appearance:

>>> from datetime import datetime
>>> datetime(2007, 1, 2) - datetime(2007, 1, 1, 0, 0, 0)
datetime.timedelta(1)
>>> str(_)
'1 day, 0:00:00'

The behaviour to the end user exposes the midnight assumption,
regardless whether it's explained by saying the constructor
makes the assumption or the subtraction makes the assumption.


-- ?!ng
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] datetime module enhancements

[Brett Cannon]

On 3/9/07, Christian Heimes <[EMAIL PROTECTED]> wrote:
> Collin Winter schrieb:
> > I can't say I'm well-versed in the intricacies of date/time issues,
> > but what you say makes sense. This is exactly why I brought this patch
> > up here : )
>
> Oh h...! Seems like I've opened a can of worms here. I only wanted to
> add some minor enhancements and now it looks like the improvements and
> the datetime module have to be carefully defined and PEPed.
>
> I'm trying to summarize the discussed issues and proposals:
>
>  * Change the underlying time_t type (Unix timestamp) to use a unsigned
> 64bit integer even on 32 bit operating systems.
>
>  * Carefully define the comparison between date and datetime objects.
>
>  * int(timedelta) and float(timedelta) returns seconds
>
>  * Add methods to datetime to cast from/to Julian Date Number (also MJD
> and RJD)
>
>  * What about moving the C extension to _datetime so we can implement
> some non time consuming extensions in Python?
>

When a use-case comes up we can make the move, but we don't need to do
it pre-emptively.

>  * What do you think about including PyTz in the Python core? PyTz is
> really, REALLY useful when one has to deal with time zones.
> http://pytz.sourceforge.net/
>

What is wrong with datetime's tzinfo objects?  You need to show why
datetime is not sufficient and why fixing it is not worth it and how
it is better to bring in another chunk of code.  And then we can
discuss code standards, the author of PyTz stepping forward to
contribute the code and maintain it, etc.

>  * The dateutil package contains additional features which may prove as
> useful: http://labix.org/python-dateutil

If someone wants to port features from dateutil to datetime, that's
fine, but they just need to be worth it.

-Brett
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] datetime module enhancements

[André Malo]

* Brett Cannon wrote:

> On 3/9/07, Christian Heimes <[EMAIL PROTECTED]> wrote:
> >  * What do you think about including PyTz in the Python core? PyTz is
> > really, REALLY useful when one has to deal with time zones.
> > http://pytz.sourceforge.net/
>
> What is wrong with datetime's tzinfo objects?

There aren't any. pytz fills that gap.

But I think, pytz has no place in the stdlib anyway, because it has 
reasonably different release cycles (every time the timezone tables 
change).

nd
-- 
"Das Verhalten von Gates hatte mir bewiesen, dass ich auf ihn und seine
beiden Gefährten nicht zu zählen brauchte" -- Karl May, "Winnetou III"

Im Westen was neues: 
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] datetime module enhancements

[Brett Cannon]

On 3/9/07, André Malo <[EMAIL PROTECTED]> wrote:
> * Brett Cannon wrote:
>
> > On 3/9/07, Christian Heimes <[EMAIL PROTECTED]> wrote:
> > >  * What do you think about including PyTz in the Python core? PyTz is
> > > really, REALLY useful when one has to deal with time zones.
> > > http://pytz.sourceforge.net/
> >
> > What is wrong with datetime's tzinfo objects?
>
> There aren't any. pytz fills that gap.

I remember some discussion about why tzinfo objects were not initially
included in the stdlib.  Don't remember why they were not (may just
have been no one wanted to bother to write them).

>
> But I think, pytz has no place in the stdlib anyway, because it has
> reasonably different release cycles (every time the timezone tables
> change).

That may have been why they were left out.

-Brett
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] datetime module enhancements

[Christian Heimes]

Brett Cannon schrieb:
> What is wrong with datetime's tzinfo objects?  You need to show why
> datetime is not sufficient and why fixing it is not worth it and how
> it is better to bring in another chunk of code.  And then we can
> discuss code standards, the author of PyTz stepping forward to
> contribute the code and maintain it, etc.

Nothing is wrong with the datetime's tzinfo *class*. PyTz is not an
alternative implementation of the datetime.tzinfo *class*. It's a
database containing several hundreds of datetime.tzinfo *objects* for
various time zones.

More precisely:
The tz objects in PyTz are based on datetime.tzinfo but they are
optimized for static offsets and dynamic offsets from UTC. The objects
are also optimized for size (singletons) and pickling. The package was
written by Stuart Bishop. He is a well known Python developer and known
for high quality code. The code is well written and covered by lots of
unit and doc tests.

>From the README.txt
pytz brings the Olson tz database into Python. This library allows
accurate and cross platform timezone calculations using Python 2.3
or higher. It also solves the issue of ambiguous times at the end
of daylight savings, which you can read more about in the Python
Library Reference (datetime.tzinfo). Amost all (over 540) of the Olson
timezones are supported.

Christian

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

Re: [Python-Dev] datetime module enhancements

[Christian Heimes]

André Malo schrieb:
> But I think, pytz has no place in the stdlib anyway, because it has 
> reasonably different release cycles (every time the timezone tables 
> change).

The release cycles are a possible issue but what about PEP 297?
http://www.python.org/dev/peps/pep-0297/ It sounds like a perfect
solution for the issue.

Christian

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

Re: [Python-Dev] Encouraging developers

[Neal Norwitz]

On 3/7/07, Facundo Batista <[EMAIL PROTECTED]> wrote:
> A.M. Kuchling wrote:
>
> > FWIW, I have a related perception that we aren't getting new core
> > developers. These two problems are probably related: people don't get
> > patches processed and don't become core developers, and we don't have
> > enough core developers to process patches in a timely way.  And so
> > we're stuck.
> >
> > Any ideas for fixing this problem?
>
> I think that there's a barrier entry: there's no place to ask for help
> on silly problems when you're trying to help (!).
>
> Let me explain my bad english wording, with an example. Yesterday night
> I started modifying socket.py and test_socket.py. "Of course", I said,
> "let's see if the tests pass ok *before* start changing anything".
>
> Went to ~/devel/reps/python/trunk/Lib, and made:
>
>   $ python2.5 test/test_socket.py...   Wrong!
>
> Damn! Tried a lot of stuff...
>
>   $ cd test
>   $ python2.5 test_socket.py...   Wrong!
>   $ python2.5 regrtest.py test_socket ... Wrong!
>   $ python2.5 regrtest.py test_socket.py ... Wrong!
>   $ python2.5 regrtest.py socket ... Wrong!
>
> And thousand more combinations. The best I could do is actually execute
> the tests, but python was getting the installed socket module, and not
> the repository socket module (even that I was in the same directory of
> the latter).
>
> I didn't know what to try. I was stuck. This never happened to me when
> working on Decimal. What went wrong in my head in the middle?
>
> I finally understood the problem, and build python from the repository,
> and made the tests from *this* python (actually, this was an easy step
> because I'm on Ubuntu, but *I* would be dead if working in Windows, for
> example).
>
> Ok. *Me*, that I'm not ashame of asking what I don't know, if I didn't
> resolve it I'd finally asked in python-dev. But how many people would
> have throw the towel withoug getting so far?
>
> How many people want to submit a patch, or even a bug, or finds a patch
> to review, but don't know how to do something and thinks that python-dev
> is not the place to ask (too high minds and experienced people and
> everything)?
>
> What I propose is a dedicated place (mailing list, for example), that is
> something like a place where you can go and ask the silliest questions
> about helping in the developing process.
>
> - How can I know if a patch is still open?
>
> - I found a problem, and know how to fix it, but what else need to do?
>
> - Found a problem in the docs, for this I must submit a patch or tell
> something about it? How?
>
> - I found an error in the docs, and fixed it, but I'm spanish speaker
> and my english sucks, can I submit a patch with bad wording or I must
> ask somebody to write it ok?
>
> Me, for example, has an actual question to this list: "How can I know,
> if I change something in the doc's .tex files, that I'm not broking
> the TeX document structure?".

I think this was answered in a separate thread, but I want to make
sure everyone sees it here.

In addition to the buildbots that run on every checkin (more or less),
Misc/build.sh runs every 12 hours.  This script does a full build,
make install, runs the regression test suite *with refleak checking*,
and builds the docs.  Any errors are sent to python-checkins.  The
results from building the docs are here:

http://docs.python.org/dev/  - for the trunk (ie, currently 2.6)
http://docs.python.org/dev/2.5/

The results from running Misc/build.sh are found by adding results/ to
either of the URLs above.  If the doc doesn't build, the development
versions of the doc are not overwritten.

So to answer your question, you will know if you break a test or
documentation by following python-checkins.  Here is an example of
when a refleak was detected:

http://mail.python.org/pipermail/python-checkins/2007-February/058689.html

Here's an example of when there was a doc failure:

http://mail.python.org/pipermail/python-checkins/2006-February/049409.html

I've tried to make it hard to screw up Python and not notice.  The
easiest way to do it now is to check in something without a test.  If
everything is checked in with a test, it will be very hard to screw
something up and for it to not be noticed by some automated system.
It would also be nice to run texcheck.py in build.sh to catch things
like unbalanced parens.

n
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Encouraging developers

[Neal Norwitz]

On 3/5/07, Scott Dial <[EMAIL PROTECTED]> wrote:
>
> If nothing else, as an outsider there is no way to know why your patch
> gets ignored while others get swiftly dealt with. Any sort of
> information like this would at least provide more transparency in what
> may appear to be elitest processes.

Have you read the developer FAQ?  http://www.python.org/dev/faq/

If we answered your questions in the FAQ, would that help?  Can you
come up with a list of questions that the FAQ doesn't address?

If you haven't read the FAQ or didn't know it existed, where would you
look for answers?  Where can we make this info available?

I don't believe there is anything elitist about it.  I can see how one
could get many opinions given that it's opaque from the outside.  It's
been described, but I'll re-iterate.  It's completely up to the
reviewers.  There are only about a handful of people that I know of
that review patches.  I was one of those people up until about 2
months ago when I got just too much mail and have to archive most of
the patches mail I get.  I also look through the bugs pretty regularly
to see if there are any very serious or very easy bugs to fix.

When I reviewed patches, I would only look at ones I thought I could
address in however much time I had and felt qualified to apply.  If I
don't know enough about a subject area, I typically don't look.  I
can't tell if a swizzle method would really be appropriate for a
boombah since I didn't even know python had a boombah.  Sometimes I
comment on patches and don't get a response.

We should probably be a lot more aggressive about closing bugs and
patches without response.  Unfortunately many fall into this category.

Other bugs/patches go something like this:  the documentation could be
clearer.  If I understand the current doc, there's no hope of me
making it clearer.  More guidance by others who might be able to
provide concrete options (e.g. specific wording), can allow us to make
a decision.

n
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Import APIs

[Georg Brandl]

Currently, all C code that needs to import a module uses
PyImport_ImportModule which
(1) calls __builtin__.__import__
(2) attempts relative imports

Most of the time, though, at least (2) is wrong.
If we want to keep (1), PyImport_ImportModuleLevel can't be
used as a replacement.
So there should be a new API, called PyImport_ImportAbsolute
that gets a flag whether relative import should be allowed.

Georg

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