this bug or not...
OK, that seems to be the source of your confusion, then. This has
nothing to do with PEP-416.
We are talking about issue Issue 14417 (like it says in the subject),
which in turn is a reaction to the fix for issue 14205.
--David
__
turnip,
> watch
>
> I wonder if something with tick would work? (Even though it returns a float.
> :-)
>
> If all else fails, I'd go with turnip.
We could call it "alice"[*]: sometimes it goes fast, sometimes it goes slow,
sometimes it even goes backward, but
again: issue 14417 has *nothing* to do with immutable dicts.
Please carefully read over issue 14205 in order to understand what we
are talking about so that you can contribute to the discussion.
--David
___
Python-Dev mailing list
Python-Dev@python.org
htt
ith leaving the
RuntimeError as a signal that the application needs to add some locking.
My concern was that we'd have working production code that would start
breaking. If it takes a *lot* of threads or a *lot* of mutation to
trigger it, then it is going to be a
I think he does use hg now for cpython development.)
I think Benjamin was the one who used git, but I'm probably
misremembering.
--David
___
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
ects the various arguments.
Then we can bikeshed some more based on the language in the PEP :)
--David
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/py
ld also occur during normal
web submissions if they happen to happen at the same time, which is
a little bit worrisome.
If anyone has any Xapien experience and would be willing to help out with
debugging this and/or some indexing issues, please let me know :)
--David
___
on the task would then do a rewrite, asking you questions
to fill in any details that aren't clear from the rough draft.
Thank, you, by the way, for all the work you are doing.
--David
___
Python-Dev mailing list
Python-Dev@python.org
http://mail
On Thu, 05 Apr 2012 17:34:07 +0300, Andrew Svetlov
wrote:
> Thank you, David.
> Is separate repo clone located at hg.python.org good enough? Or maybe
> there are better way to do it?
That sounds like a good plan to me.
--David
___
Python-De
function) that just returns True or False? Maybe we do, if actually
creating the clock could raise an error even if exists, as is the case
for 'open'.
(But unless I'm confused none of this has anything to do with Victor's
PEP as currently proposed :)
--David
___
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
est
place for a delete request. If this becomes a burden at some point,
someone will figure out a secure way to automate it...security is the
reason it isn't automated now.
--David
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.
On Mon, 09 Apr 2012 13:34:25 -0400, Terry Reedy wrote:
>
> On 4/9/2012 9:13 AM, r.david.murray wrote:
> > http://hg.python.org/cpython/rev/eff551437abd
> > changeset: 76176:eff551437abd
> > user:R David Murray
> > date:Mon Apr 09 08:55:42 2012 -0
inherent ambiguity in what the term means. If you
use it to measure an interval, then I think most people would agree
automatically that it is equivalent to "real time". But outside of
interval measurement, there is ambiguity.
So I think the definition in the PEP is correct.
--Dav
For those of you who had noticed that since the upgrade the tracker
search hasn't been returning a complete set of hits on typical searches,
this should now be fixed.
--David
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.pytho
emi-readable code, surely
we do have source code for the pre-frozen module, and it is just a matter
of convincing hg that the bytecode is binary, not text?
Brett's earlier thought of compiling from source as a *fallback* makes
sense to me. I'd rather not add overhead to startup that we c
impression is that our usual solution for this is to make sure the
timestamps are correct in distributed tarballs, so that the hg-dependent
machinery is not invoked when building from a release tarball. Is this
case any different?
--David
___
Pytho
On Tue, 17 Apr 2012 01:11:14 +0200, Georg Brandl wrote:
> On 16.04.2012 18:15, R. David Murray wrote:
> > I don't see how depending on Cython is better than depending on having
> > an existing Python.
>
> No, it's not just an existing Python, it is (at least c
le that way, factor it out.
--David
___
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
d is smaller than the clock accuracy,
you want the number of bits.
(Yes, I'm using accuracy in a slightly different sense here...I think
we don't have the right words for this.)
To use other words, what the users cares about are the error bars on
the returned result.
--David
_
We're seeing segfuilts on the buildbots now. Example:
http://www.python.org/dev/buildbot/all/builders/x86%20Ubuntu%20Shared%203.x/builds/5715
On Wed, 18 Apr 2012 23:39:34 +1000, Nick Coghlan wrote:
> On Wed, Apr 18, 2012 at 11:31 PM, brian.curtin
> wrote:
> > - Â Â if (name == NULL)
> > + Â
Please submit a bug report at bugs.python.org. Bugs posted to this
mailing list tend to get forgotten unless a tracker issue is created.
On Wed, 18 Apr 2012 20:54:28 +0800, Leo wrote:
> The doc says supported as in
> http://docs.python.org/library/webbrowser.html
>
> but the code has been delet
tandard definitions in US English that I learned in physics
> and statistics decades ago.
My problem was that I was confusing this definition of precision with
the "precision" of the computer representation of the number (that is,
the number of digits in the returned result).
--
some core developers (present or
future) would prefer to learn Cython over learning C [*].
--David
[*] For this you may actually want to read "learning to modify the Python
C codebase", since in fact I know how to program in C, I just prefer to
do as little of it as possible, and so haven&#
mail
address associated with the hg update email is python-dev, the bounce
gets sent here.
There are currently only three people who do maintenance work on the
tracker (it used to be just one), and none of us have found time to
try to figure out a fix yet.
--David
ontainer types at the top of the collections module docs
The short answer is yes, someone would mind, which is why it is where it
is. Read the ticket for more: http://bugs.python.org/issue14386.
--David
___
Python-Dev mailing list
Python-De
7;m pretty sure that anything heavily using sqlalchemy will benefit,
so that would be a good place to look for a real-world benchmark.
--David
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsu
On Thu, 26 Apr 2012 17:07:46 +0200, Stefano Taschini wrote:
> May I suggest that http://bugs.python.org/issue8767 be reopened, to make
> things clear?
Done.
--David
PS: we prefer no top-posting on this list. It makes it far easier
to retain just enough context to make a message stand
work in progress.
There are, by the way, many things documented in the "library"
documentation that are in fact provided by the language implementation
itself. All of the fundamental types, for example.
--David
(*) the Oracle lawyers sometimes seem to be trying to get
the judge and jury
d). I don't know why I wouldn't
have expected it to work, I just didn't.
That said, could this insertion of '' only happen when the interactive
prompt is actually posted, and otherwise use cwd?
--David
___
Python-Dev mailing lis
be considered provisional
and subject to improvement in 3.4 based on what we learn by having it
actually out there in the field and getting tested.
--David
___
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
gled variable declarations and code"? Do we *unofficially*
> > > support any? And if we do, what do we gain?
> >
> > Well, there's this one called MSVC, which we support quite officially.
>
> Not sure if comic genius or can't rhyme.
I had trouble with that
ng terminology than
> dynamic type creation.
Yeah, but that's the statement form. I think of the characters in the
.py file as the definition. If I'm creating a class dynamically...I'm
creating(*) it, not defining it.
I don't think it's a big deal, though. Either
sphinx docs should be the more expansive version of the
documentation.
Yes, this creates a double-maintenance burden, and the two sometimes
slip of of sync. But it is a long-standing rule and will doubtless
require considerable bikeshedding if we want to change it
te an "inner loop", but it
isn't an outer one either.
That said, the header parsing logic that is also invoked by the process
of returning a header under the new policy is going to outweigh the
class construction overhead, I'm pretty sure.
--David
_
definition pushing
the limits of what's possible.
--David
___
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
On Tue, 01 May 2012 10:55:03 -0400, Barry Warsaw wrote:
> On May 01, 2012, at 10:40 AM, R. David Murray wrote:
> >I guess it's time to talk about my plans for this one :)
>
> Thanks for the update RDM. I really wish I had more time to contribute to
> email6, but I
The fact that none of us knew about it may say something about its
effectiveness, though.
As long as it does exist, there ought to be a parallel docs2.python.org.
--David
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/l
On Mon, 21 May 2012 11:19:56 -0400, David Malcolm wrote:
> On Fri, 2012-05-18 at 14:24 -0400, Barry Warsaw wrote:
> > At what point should we cut over docs.python.org to point to the Python 3
> > documentation by default? Wouldn't this be an easy bit to flip in order to
>
n
> email. The relevant people will be notified or assigned if a bug is
> entered.
It was already reported by someone else:
http://bugs.python.org/issue12641
--David
___
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
On Sat, 26 May 2012 09:14:07 +0200, Georg Brandl wrote:
> Am 26.05.2012 00:44, schrieb r.david.murray:
> > http://hg.python.org/cpython/rev/0189b9d2d6bc
> > changeset: 77148:0189b9d2d6bc
> > user:R David Murray
> > date:Fri May 25 18:42:14 2012 -040
t run the unittests either.
> There are crash bugs in the release build and I wanted to repro it using the
> debug version , but failed.
> This is likely to be related to the virtualenv changes, perhaps.
> see http://bugs.python.org/issue14952
The &q
escribed approach), I believe that
> last sentence should be:
>
> "The full name of a generated test is a 'test_' prefix, the portion
> of the test function name after the '_as_' separator, plus an '_',
> plus the name derived as explained above.&quo
returns ``['ab c\n', '\n, 'de fg\r', 'kl\r\n']``.
>
> s/splinelines/splitlines/
Oops.
> Maybe also show what split() would do for that string?
I'd rather not, since the split examples are just above it in
the docs.
--David
g 6 repetitions
> 123456
> ..
> test_smtplib leaked [154, 154, 154] references, sum=462
Gah. Looks like a copy and paste error by one of the many people
(including me) who contributed to the last smtpd patch. Should be fixed
by 079c1942eedf.
--David
___
ecorators.extend(cls.__dict__.get("__decorators__", ())
> # Apply the decorators in "Last In, First Out" order, just like
> unwinding a chain of super() calls
> for deco in reversed(decorators):
> cls = deco(cls)
Assuming I got this right (no guarantees
ith no information
about what timezone it originated from (coded as - per RFC 5322),
while an aware datetime will generate an accurate offset (+ for
"really UTC", and as appropriate for others).
So in some sense I've already nudged the stdlib in this
direction...unless I get o
't think we currently actually test the doctests
in the python docs and (2) I'm following the style of the surrounding text
(the split examples just above this are in the same inline style. Oh, and
(3) it would make the text longer, which could be considered a nega
ing with read-only because it is easy to make them mutable later
but pretty much impossible (backward compatibility wise) to make them
immutable if they start mutable.
I see the signature object as a very parallel case to this, except that
it is already obvious that having them be a mutable copy
k you meant __str__ = __repr__. __repr__ is the more fundamental
of the two, and if there is no __str__, it defaults to __repr__.
IMO the __repr__ should make it clear that it is a signature object
somehow.
--David
___
Python-Dev mailing list
Python-Dev@py
On Fri, 08 Jun 2012 07:20:55 -0400, Tres Seaver wrote:
> On 06/07/2012 08:55 AM, R. David Murray wrote:
> > On Thu, 07 Jun 2012 11:08:09 +0100, Sam Partington
> > wrote:
>
> >> Wouldn't that be better written as a doctest and so avoid any other
> >> typ
.
And yes, I agree with your understanding that fixing tests (especially
for things like resources not getting cleaned up correctly) is
appreciated for the 2.7 tests. We should of course verify whether
or not similar changes are needed for Python3.
As for path to get them in...if you have any questio
the email package, I need a way to get from 'now' to an RFC 5322
date/time string, and whatever that way is it needs to (1) be unambiguous
what time in what timzeone offset it is when the user passes it to me,
and (2) it needs to interoperate with date/time+timezone-offset that is
obta
cal reason I can see why -O should be required for a .pyo
file to be used (*if* it is the only thing around) is if it won't *run*
without the -O switch. Is there any expectation that that will ever be
the case?
On the other hand, not wanting make any extra effort to support sourceless
distri
On Wed, 13 Jun 2012 11:20:24 -0700, Toshio Kuratomi wrote:
> On Wed, Jun 13, 2012 at 01:58:10PM -0400, R. David Murray wrote:
> >
> > OK, but you didn't answer the question :). If I understand correctly,
> > everything you said applies to *writing* the bytecode, not r
On Wed, 13 Jun 2012 20:46:50 +0200, Antoine Pitrou wrote:
> On Wed, 13 Jun 2012 11:20:24 -0700
> Toshio Kuratomi wrote:
> > On Wed, Jun 13, 2012 at 01:58:10PM -0400, R. David Murray wrote:
> > >
> > > OK, but you didn't answer the question :). If I underst
debug__ setting is supposed to be process-global
Both of these are good reasons. IMO the issue should be closed with a
documentation fix, which could optionally include either or both of the
above motivations.
--David
___
Python-Dev mailing
n normal and -OO is around a 10%
savings (about 2MB) in program DATA size at startup, and that makes a
difference for an ap running in a memory constrained environment.
A docstring stripper would enable the bulk of that savings, but it is
still nice to be able to omit code (such as debug log
's ear,
"integral port number" sounds wrong, probably because the port number
has to be an integer, so it sounds like saying "an integral integer".
The important thing the doc needs to convey is that the *port* argument
actually needs to be an *integer*, as opposed to a string.
--David
___
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
l parameters that if they occur on the same
object at the same time would be invalid is a code smell. If the thing
can be one and only one of a list of possible types, it makes sense to
me that this be indicated as a single attribute with a list of possible
values, rather than a set of
islower :).
I'm not going to claim that there was that much foresight in the creation
of those two methods. I will, however, note that we aren't perfectly
consistent in the application of our rules.
--David
___
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
ted features. That's a
> > perfectly reasonable option.
>
> What would the validate() function for os.close do?
Why would you need one?
--David
___
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
s consistency.
Without the deepcopy, sometimes what you get back from the
inspect function is freely modifiable and sometimes it is not.
That inconsistency is a bad thing.
--David
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python
it ends up just getting in the way
of wider adoption of the most useful pieces.
For what it is worth, notice that perl does not use organization names,
it uses functional names.
Which languages other than Java use organizational names?
--David
___
Python-D
re*, only the *forks*. Within the fork, the software itself
retains the same name...that's the whole point.
--David
___
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
(). This patch just changed it to not do a full
> rewrite when flush() is called. Having a partially written message in
> the end of your mailbox doesn't seem like a fatal corruption to me.
>
> Furthermore, I (and R. David Murray) think this is not so surprising
> for users.
x27;s somewhat amusing. Last upgrade, /console made a traceback
and /waterfall worked fine, this upgrade it is the reverse.
--David
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://m
;)'
> 100 loops, best of 3: 0.685 usec per loop
>
> some woman wrote this
I don't have any idea what any of your recent posts mean, but this
one appears to be offensive. I would appreciate it if you would stop
posting until you have something substantive to say, and can do s
aking for myself, but I really have trouble
> parsing non-trivial relative imports, and I personally prefer when
> people use absolute imports (e.g. "from test import support").
Agreed. I don't see that there is any reason to use relative
imports in the stdlib.
--D
to open an
issue for doing that for hashlib, in addition to one for fixing this
particular issue with the Python version.
--David
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mai
for the thing that actually matters, rather than
testing a constant with a much broader meaning. Yes, in this case the
results are the same, but IMO it is better programming practice to test
the thing that actually matters when you can.
--David
___
P
Benjamin sent me this message separately(*) privately and I responded
privately. Here is my response.
(*) or his mailer did
On Sun, 22 Jul 2012 20:22:50 +0100, Oscar Benjamin
wrote:
> On 22 July 2012 14:08, R. David Murray wrote:
>
> > On Sun, 22 Jul 2012 11:21:38 +0300, anato
ing overlap in next Friday's
report. (Not that that should matter much unless someone is
using them to track week-to-week statistics.)
--David
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubs
I don't know why the Dev Guide says the opposite for :c:func:
> and is silent on :meth:.)
To clarify: :func: automatically adds the ()s, so if you put them in
the source you get double: invalidate_caches()(). As Chris said,
use the 'alternate text' form if you want to show a
With that applied, all the test_cmath tests pass again (without any
> changes to the test file).
>
> Thoughts?
Open an issue on the tracker and make mark.dickinson (and maybe skrah)
nosy.
--David
___
Python-Dev mailing list
Python-Dev@python.
the the time. Another issue or known
> and un-fixable?
At one point there was an issue with certain spellings taking a fast path
(avoiding a codec lookup?) and other spellings not. I thought we'd fixed
that, but perhaps we didn't?
--David
__
rites, and to fix RawIO.writelines() to always do complete
> writes.
I think writelines doing a partial write is counter-intuitive in the
Python context (as well as being contrary to the existing
documentation), so I think I'd favor this.
--David
27;foobar' example might make this sentence
> > more understandable.
>
> Added.
I think it is an important and subtle point that this happens at "compile
time" rather than "run time". Subtle in that it is not at
spit out
> files or JSON or more or less whatever else you want.
That isn't going to be the right set of keys for Trent's purposes
(though it is likely to be a subset). The keyfile we use for the hg
repository is.
--David
___
Python-Dev m
use
> > problems.
>
> When discussing "filemode|[compression]" modes, the docs say:
>
> However, such a TarFile object is limited in that it does not
> allow to be accessed randomly
>
> I'm not a tarfile expert, but extracting a single file sounds like
> random access to me. If it was the first file in the archive (or there
> was only one file) it probably wouldn't count as random access.
There is an open doc bug for this:
http://bugs.python.org/issue10436
--David
___
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
still have a (vetted) registry for "official" names, if
we wanted. That would follow the MIME model. Or we can still have a
separate registry, but only "qualified" (namespaced) names are open for
anyone to register, without any expiration dates.
--
R. David Murray
If you
xpires,
and a *new* registration is entered with a different meaning, but
packages still exist on PyPI that have the key with the old meaning.
That seems likely to happen in practice. Or if it doesn't, then
allowing for the recycling of names probably isn't important.
--
R. Davi
On Tue, 28 Aug 2012 18:47:16 +0200, =?ISO-8859-15?Q?=22Martin_v=2E_L=F6wis=22?=
wrote:
> Am 28.08.12 18:27, schrieb R. David Murray:
> > The problem Donald is asking about is: the old registration expires,
> > and a *new* registration is entered with a different meaning, bu
and are therefore most likely to be found there, keep the same
IRC handle for a long time (I've had mine, bitdancer, since 1995 or so).
So I think there would be utility in such a list even if the updates
were spotty.
--
R. David Murray
If you like the work I do for Python, you can
xpect.
It also allows for typo detection, which automatically interpreting
prefix strings as extensions names would not.
--
R. David Murray
If you like the work I do for Python, you can enable me to spend more
time doing it by supporting me here: http://gittip.com/bitdancer
want to
assign meaning to the line separators. You can do that with a custom
policy and thus still be able the use the email parsing infrastructure
to read and write the files. I'll be glad to help out with creating
the custom policy once we've reached that stage of the process.
--
R.
il module facilities to parse
> Metadata.
The policy has hooks that support this. A policy gets handed the source
line complete with the line breaks, determines what gets stored in the
model, and also gets to control what gets handed back to the application
when a header is retrieved from th
ustaining
Engineering" this year. From this point on it is just "Mature Product
Support". Not sure exactly what that means, other than that Tru64 is
definitely a dying platform.
--David
___
Python-Dev mailing list
Python-Dev@python.
es is entirely controlled by Sphinx, and thus by the sources checked
in to the code repository.
--David
___
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
.7, which are all
> affected by this bug (because the original fix for 12776 was applied to all
> three branches).
>
> Georg, I would like to apply this to the 3.3 branch.
The 12776 fix isn't going to be in 3.3, so I don't think this is a
pressing issue. We can take our time to make sure we have the correct
fix. It is, however, a release blocker for 2.7.4, 3.2.4, and 3.3.1.
--David
___
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
On Tue, 11 Sep 2012 15:08:26 -0400, Barry Warsaw wrote:
> On Sep 11, 2012, at 12:19 PM, R. David Murray wrote:
>
> >The 12776 fix isn't going to be in 3.3, so I don't think this is a
> >pressing issue. We can take our time to make sure we have the correct
> &
g.
When the removal was being pondered, the possibility of keeping certain
bits that were more ready than others was discussed. Perhaps the best
way forward is to put it back in bits, with the most finished (and PEP
relevant) stuff going in first. That might also give non-packaging
people bite-siz
o set it up.
--David
___
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
think I for one will probably be available during the day (EST) on
the 27th.
--David
___
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
nge in
> semantics. Any code changes required are described in the Porting Python
> code <http://docs.python.org/py3k/whatsnew/3.3.html#porting-python-code>
> section of this document; it will only affect code that currently
> manipulates import or calls it programmatically
hat shouldn't be.
This appears to be a Sphinx bug of some sort. The ReST source
is correct.
--David
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailma
database that is hard-wired in past Pythons.
>
> But at worst, an outdated unicode database will be missing data right?
>
> Doesn't an outdated timezone db have the risk of returning *incorrect* data?
Yes. And the timezeone database is much more volatile than the unicode
database
instead).
Emulator? That makes no sense, I'm afraid.
I think we are talking here about incorporating pytz into the
stdlib. The only question is how to manage the Olson database
on Windows, which has *always* been the question.
--David
___
Pyt
Gah, ignore half of that last post. I think Lennart is talking
about incorporating the missing pytz *functionality* into
the stdlib.
--David
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
On Mon, 01 Oct 2012 21:59:03 +0200, Lennart Regebro wrote:
> On Mon, Oct 1, 2012 at 9:02 PM, R. David Murray wrote:
> > On Tue, 02 Oct 2012 00:18:10 +0530, Nick Coghlan wrote:
> >> Reminder to everyone: the current state of the art for getting up to
> >> date tz info
> excellent. If they want to meet up on another date, this is also
> excellent. It doesn't need to be a one time thing :)
Yes. I think there are people already trying to to (or perhaps
even succeeding) in arranging spaces for that date, so changing
it would be a disruption to those plans.
1901 - 2000 of 2106 matches
Mail list logo
