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
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.
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
>
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 per
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
> co
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.sourc
* 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
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.
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 ti
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 t
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 e
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 lik
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
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
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
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 o
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
"\"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)
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 curre
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. Th
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 specif
(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_posixpa
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.
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 curre
Ž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
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)
[Ž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
Unsu
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
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 i
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 Ljublj
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 t
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:
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 compute
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
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 libra
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 time
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 curre
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-b
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 wo
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
> >>> rou
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. W
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 str
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
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
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
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 application
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
47 matches
Mail list logo
