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
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
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
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
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
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
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
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
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
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
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
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
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
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,
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
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:
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
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,
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
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!
[Ž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
Ž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
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
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
(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)
+++
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
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
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
\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
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
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
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
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
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
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
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
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
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
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
* 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
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/
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
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
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
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
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
46 matches
Mail list logo
