Re: [Python-Dev] backporting stdlib 2.7.x from pypy to cpython

[Nick Coghlan]

On Tue, Jun 12, 2012 at 3:24 PM, Terry Reedy  wrote:
> This is simple to try and see what happens.
> [X] or [XI] for X(cross) implementation.

To allow easier transition to a separate list (if that seems necessary
at a later date), my preferred colour for the bikeshed is
[compatibility-sig].

I think a subject line marker is actually a reasonable approach - we
can just add the header to the subject line whenever we reach a point
in the discussion where we're asking "it would be good to get feedback
from PyPy/Jython/IronPython/etc on this". It serves exactly the same
purpose as posting the question to a separate list would, without
risking splitting the discussion.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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] backporting stdlib 2.7.x from pypy to cpython

[Terry Reedy]

On 6/11/2012 11:13 PM, fwierzbi...@gmail.com wrote:

On Sun, Jun 10, 2012 at 11:58 PM, Nick Coghlan  wrote:



2. As 1, but we adopt a subject line convention to make it easier to
filter out general python-dev traffic for those that are just
interested in cross-vm questions



(2) and (3) work for me - I try to do (1) but often miss discussions
until they have gone stale.

I bet (2) would work well enough as long as there are enough
interested participants to remember to add the conventional string to
the subject of an ongoing discussion. It would be very easy for me to
add a filter for such a string.


This is simple to try and see what happens.
[X] or [XI] for X(cross) implementation.

---
Terry Jan Reedy

___
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] TZ-aware local time

[Ben Finney]

Guido van Rossum  writes:

> On Mon, Jun 11, 2012 at 7:10 PM, Ben Finney  
> wrote:
> > Unambiguous storage of absolute time can be achieved with POSIX
> > timestamps, but that is certainly not the only nor best way to do
> > it.
> >
> > For example, RFC 5322 specifies a standard serialisation for
> > timestamp values that is in very wide usage, and those values are
> > valid for transforming to a ‘datetime.datetime’ value. POSIX
> > timestamps are not a necessary part of the data model.
>
> To the contrary, without the POSIX timestamp model to define the
> equivalency between the same point in time expressed using different
> timezones, sane comparisons and arithmetic on timestamps would be
> impossible.

Why is the POSIX timestamp model the only possible model? To the
contrary, there are many representations with different tradeoffs but
with the common properties you name (“equivalency between the same point
in time expressed using different timezones”).

I'm objecting to your assertion that the *specific* data format of POSIX
timestamps is necessary for this, rather than being a contingent format
that is one of many real world formats used for timestamps.

> > Another example is database fields storing timestamp values; they are
> > surely a very common input for Python ‘datetime.datetime’ values.
>
> But how does a database represent timestamps *internally*?

My point is that the programmer using Python ‘datetime’, and not dealing
with POSIX timestamps at any point, should not need to care how
‘datetime’ represents its values internally.

You said “the *input* […] should be a POSIX timestamp, not a datetime
object.”, but these use cases (RFC 5322 timestamps, database timestamp
field values) have other inputs for timestamp values and there's no need
for a POSIX timestamp in the data model.

The programmer for these common use cases is dealing with input that is
not POSIX timestamps, their output is not POSIX timestamps, and the data
processing doesn't have any need for the concept of “seconds since
epoch”. So why claim that the POSIX timestamp is necessary for such use
cases?

> > For many use cases a different storage is appropriate, a different
> > input is appropriate, and POSIX timestamps are irrelevant for those
> > use cases.
>
> POSIX timestamps are no good for human-entered input or human-readable
> output. But they are hard to beat for internal storage.

Perhaps so, and perhaps not. Either way, that's not an argument for
requiring the user of ‘datetime’ to deal with that internal
representation.

The ‘datetime’ module provides a useful abstraction that allows
different serialisation, without tying the programmer to POSIX
timestamps.

> >> > .. Users should be required to understand POSIX timestamps and
> >> > the importance of UTC before they try to work with multiple
> >> > timezones.
> >
> > Why? If they are using, for example, a PostgreSQL ‘TIMESTAMP’ object
> > to store the value, and manipulating it with Python
> > ‘datetime.datetime’, why should they have to know anything about
> > POSIX timestamps?
>
> So they'll understand that midnight in New York != midnight In San
> Francisco, while 4pm in New York == 1pm in San Francisco. And so they
> understand that, while the difference between New York and San
> Francisco time is always 3 hours, the difference between San Francisco
> time and Sydney time can vary by two hours.

You made two assertions in “Users should be required to understand POSIX
timestamps and the importance of UTC before they try to work with
multiple timezones.”

I'm not objecting to “Users should be required to understand the
importance of UTC before they try to work with multiple timezones”.

I am objecting to “Users should be required to understand POSIX
timestamps before they try to work with multiple timezones”.

Your argument about timezones is irrelevant to my objection about
requiring users to understand POSIX timestamps.

> IMO you ignore the underlying POSIX timestamps at your peril as soon
> as you are comparing timestamps.

If another representation (e.g. a database field) allows the comparison
safely, why require the programmer to understand a data representation
irrelevant to their use case?

> Anyway, we're very far from the original problem statement.

That might be part of the misunderstanding, and I apologise if that
confused matters.

I don't want a useful abstraction like Python's ‘datetime’ to be
intentionally leaky, so I don't think “Users should be required to
understand POSIX timestamps before they try to work with multiple
timezones” is helpful.

That's the whole of my objection, and the only point I'm currently
arguing in this wide-ranging thread.

-- 
 \  “Whatever you do will be insignificant, but it is very |
  `\important that you do it.” —Mohandas K. Gandhi |
_o__)  |
Ben Finney

___
Python-Dev mailing li

Re: [Python-Dev] TZ-aware local time

[Guido van Rossum]

On Mon, Jun 11, 2012 at 7:10 PM, Ben Finney  wrote:
> Alexander Belopolsky  writes:
>
>> On Mon, Jun 11, 2012 at 1:01 PM, Guido van Rossum  wrote:
>> > Maybe the problem here is the *input*? It should be a POSIX
>> > timestamp, not a datetime object.
>>
>> No. "Seconds since epoch" or "POSIX" timestamp is a foreign data type
>> to the datetime module.
>
> On this point I must agree with Alexander.
>
> Unambiguous storage of absolute time can be achieved with POSIX
> timestamps, but that is certainly not the only nor best way to do it.
>
> For example, RFC 5322 specifies a standard serialisation for timestamp
> values that is in very wide usage, and those values are valid for
> transforming to a ‘datetime.datetime’ value. POSIX timestamps are
> not a necessary part of the data model.

To the contrary, without the POSIX timestamp model to define the
equivalency between the same point in time expressed using different
timezones, sane comparisons and arithmetic on timestamps would be
impossible.

> Another example is database fields storing timestamp values; they are
> surely a very common input for Python ‘datetime.datetime’ values.

But how does a database represent timestamps *internally*?

And does it store the timezone or not? I.e. can it distinguish between
two representations of the *same* point in time using different
timezones? If so, how would queries work?

> For many use cases a different storage is appropriate, a different input
> is appropriate, and POSIX timestamps are irrelevant for those use cases.

POSIX timestamps are no good for human-entered input or human-readable
output. But they are hard to beat for internal storage.

>> > .. Users should be required to understand POSIX timestamps and the
>> > importance of UTC before they try to work with multiple timezones.
>
> Why? If they are using, for example, a PostgreSQL ‘TIMESTAMP’ object to
> store the value, and manipulating it with Python ‘datetime.datetime’,
> why should they have to know anything about POSIX timestamps?

So they'll understand that midnight in New York != midnight In San
Francisco, while 4pm in New York == 1pm in San Francisco. And so they
understand that, while the difference between New York and San
Francisco time is always 3 hours, the difference between San Francisco
time and Sydney time can vary by two hours.

> On the contrary, for such use cases (and database timestamp values are
> just one such) I think it's a needless imposition on the programmer to
> force them to learn about POSIX timestamps, a data type irrelevant for
> their purposes.

IMO you ignore the underlying POSIX timestamps at your peril as soon
as you are comparing timestamps.

Anyway, we're very far from the original problem statement. If the
requirement is to represent timestamps as found in email and be able
to reproduce them exactly, you may have to store the original string
beside some parsed-out version, since there are subtleties in the
string version that are lost in parsing. Hopefully the parsed-out
version can be represented as a tz-aware datetime, and hopefully for
most purposes that's all you need (if you don't need to be able to
verify a digital signature on the text of the headers). The fixed
timezones now in the stdlib are probably best for this. The rest would
seem to be specific to the email package.

-- 
--Guido van Rossum (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] Built-in sub modules

[Nick Coghlan]

On Tue, Jun 12, 2012 at 1:17 PM, Albert Zeyer  wrote:
> I also searched a bit around and I didn't directly found any easier
> way to do this. Only a post from 2009
> (http://mail.python.org/pipermail/cplusplus-sig/2009-January/014178.html)
> which seems like a much more ugly hack.

Right, it isn't currently supported.
http://bugs.python.org/issue1644818 is a long standard feature request
to add this functionality.

For Python 3.3, the old import system (written in C) has been replaced
with importlib (written in Python). This should make it easier to
extend and experiment with builtin submodule support. An importlib
based solution should also work in Python 3.2.

Further discussions would be best directed to import-sig, until an
importlib based solution is available for consideration.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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] backporting stdlib 2.7.x from pypy to cpython

[Brett Cannon]

On Monday, June 11, 2012, Stephen J. Turnbull wrote:

> Brett Cannon writes:
>
>  > But we already have the various SIGs carry out discussions outside of
>  > python-dev and just bring forward their results to python-dev when they
> are
>  > ready. Why would this list be any different?
>
> (1) Because AIUI the main problem this list is supposed to solve is
>contacting interested parties and getting them to come to
>python-dev where the actual discussion will take place.  Almost
>certainly some of the actual discussion will take place on
>python-dev, no?  It *is* on-topic for python-dev, right?  (Guido
>seems to think so, anyway)  So it's not going to focus
>discussion the way a SIG list does.


Not necessarily. Just like discussions on SIGs can start and end there, I
see no requirement that discussions on the list end up on python-dev.


>
> (2) Because it delegates issue triage to people who don't actually
>know which of the various VMs will care about a particular change,
>so it's unlikely to be terribly accurate.
>
> (3) The SIGs attract long-term interest from a body of "usual
>suspects".  It's worth it to them to invest in the SIG list.
>While the VM folks will have a long term interest, by the current
>definition of the new list they won't be starting threads very
>often!  The people who should be starting threads are quite likely
>to have interest in only one thread, so their incentive to move it
>to the new list will be low; their natural tendency will be to
>post to python-dev and "let George move the thread if needed".
>
>
Discussions on the list would universally affect all VMs, so there is an
incentive to pay attention.


> None of that means the new list is a bad idea -- it might be accurate
> *enough* to be a big improvement, etc -- just that it clearly is
> different from the various SIGs in some important ways.
>


-- 
[sent from my iPad]
___
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] Built-in sub modules

[Albert Zeyer]

Hi,

I just created some code to support built-in sub modules.

The naive way I tried first was just to add {"Mod.Sub1.Sub2",
init_modsub1sub2} to _PyImport_Inittab. This didn't worked. Maybe it
would be a nice addition so that this works.

Mod itself, in my case, was a package directory with pure Python code.
Mod.Sub1 also. Only Mod.Sub1.Sub2 was some native code.

Now, to make it work, I added {"Mod", init_modwrapper} to
_PyImport_Inittab. init_modwrapper then first loads the package just
in the way it would have been loaded before (I copied some code from
Python/import.c). Then, in addition, it preloads Mod.Sub1 and call the
native Mod.Sub1.Sub2 initialization (this also needs some
_Py_PackageContext handling) and setups everything as needed.

An example implementation is here:
https://github.com/albertz/python-embedded/blob/master/pycryptoutils/cryptomodule.c
https://github.com/albertz/python-embedded/blob/master/pyimportconfig.c

Maybe this is useful for someone.

I also searched a bit around and I didn't directly found any easier
way to do this. Only a post from 2009
(http://mail.python.org/pipermail/cplusplus-sig/2009-January/014178.html)
which seems like a much more ugly hack.

Btw., my example implementation is part of another Python embedded
project (https://github.com/albertz/python-embedded/). It builds a
single static library with Python and PyCrypto - no external
dependencies. So far, some basic test with RSA/AES works fine. Maybe
that is also interesting to someone.

Regards,
Albert
___
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] backporting stdlib 2.7.x from pypy to cpython

[fwierzbi...@gmail.com]

On Sun, Jun 10, 2012 at 11:58 PM, Nick Coghlan  wrote:
> 1. Asking on python-dev is considered adequate. If an implementation
> wants to be consulted on changes, one or more of their developers
> *must* follow python-dev sufficiently closely that they don't miss
> cross-VM compatibility questions. (My concern is that this isn't
> reliable - we know from experience that other VMs can miss such
> questions when they're mixed in with the rest of the python-dev
> traffic)
> 2. As 1, but we adopt a subject line convention to make it easier to
> filter out general python-dev traffic for those that are just
> interested in cross-vm questions
> 3. Create a separate list for cross-VM discussions, *including*
> discussions that aren't directly relevant to Python-the-language or
> CPython-the-reference-interpreter (e.g. collaborating on a shared
> standard library fork). python-dev threads may be advertised on the
> new list if cross-VM feedback is considered particularly necessary.
(2) and (3) work for me - I try to do (1) but often miss discussions
until they have gone stale.

I bet (2) would work well enough as long as there are enough
interested participants to remember to add the conventional string to
the subject of an ongoing discussion. It would be very easy for me to
add a filter for such a string.

-Frank
___
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] backporting stdlib 2.7.x from pypy to cpython

[Stephen J. Turnbull]

Brett Cannon writes:

 > But we already have the various SIGs carry out discussions outside of
 > python-dev and just bring forward their results to python-dev when they are
 > ready. Why would this list be any different?

(1) Because AIUI the main problem this list is supposed to solve is
contacting interested parties and getting them to come to
python-dev where the actual discussion will take place.  Almost
certainly some of the actual discussion will take place on
python-dev, no?  It *is* on-topic for python-dev, right?  (Guido
seems to think so, anyway)  So it's not going to focus
discussion the way a SIG list does.

(2) Because it delegates issue triage to people who don't actually
know which of the various VMs will care about a particular change,
so it's unlikely to be terribly accurate.

(3) The SIGs attract long-term interest from a body of "usual
suspects".  It's worth it to them to invest in the SIG list.
While the VM folks will have a long term interest, by the current
definition of the new list they won't be starting threads very
often!  The people who should be starting threads are quite likely
to have interest in only one thread, so their incentive to move it
to the new list will be low; their natural tendency will be to
post to python-dev and "let George move the thread if needed".

None of that means the new list is a bad idea -- it might be accurate
*enough* to be a big improvement, etc -- just that it clearly is
different from the various SIGs in some important ways.
___
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] TZ-aware local time

[Ben Finney]

Alexander Belopolsky  writes:

> On Mon, Jun 11, 2012 at 1:01 PM, Guido van Rossum  wrote:
> > Maybe the problem here is the *input*? It should be a POSIX
> > timestamp, not a datetime object.
>
> No. "Seconds since epoch" or "POSIX" timestamp is a foreign data type
> to the datetime module.

On this point I must agree with Alexander.

Unambiguous storage of absolute time can be achieved with POSIX
timestamps, but that is certainly not the only nor best way to do it.

For example, RFC 5322 specifies a standard serialisation for timestamp
values that is in very wide usage, and those values are valid for
transforming to a ‘datetime.datetime’ value. POSIX timestamps are
not a necessary part of the data model.

Another example is database fields storing timestamp values; they are
surely a very common input for Python ‘datetime.datetime’ values.

For many use cases a different storage is appropriate, a different input
is appropriate, and POSIX timestamps are irrelevant for those use cases.

> > .. Users should be required to understand POSIX timestamps and the
> > importance of UTC before they try to work with multiple timezones.

Why? If they are using, for example, a PostgreSQL ‘TIMESTAMP’ object to
store the value, and manipulating it with Python ‘datetime.datetime’,
why should they have to know anything about POSIX timestamps?

On the contrary, for such use cases (and database timestamp values are
just one such) I think it's a needless imposition on the programmer to
force them to learn about POSIX timestamps, a data type irrelevant for
their purposes.

-- 
 \   “My business is to teach my aspirations to conform themselves |
  `\  to fact, not to try and make facts harmonise with my |
_o__)   aspirations.“ —Thomas Henry Huxley, 1860-09-23 |
Ben Finney

___
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] backporting stdlib 2.7.x from pypy to cpython

[Brett Cannon]

On Mon, Jun 11, 2012 at 12:39 PM, Barry Warsaw  wrote:

> On Jun 11, 2012, at 04:58 PM, Nick Coghlan wrote:
>
> >1. Asking on python-dev is considered adequate. If an implementation
> >wants to be consulted on changes, one or more of their developers
> >*must* follow python-dev sufficiently closely that they don't miss
> >cross-VM compatibility questions.
>
> That's certainly my preference.
>

Right, because it's easiest for you and everyone else who follows
python-dev already. =) But that doesn't improve the situation; those of us
who have needed to chat with the other VMs know the status quo is not an
optimal (or even decent) solution. I only pull anything off because I know
someone on every VM team and so I have email addresses and names. But that
shouldn't be a private email conversation, nor should it require that much
effort, especially if it requires pulling in someone from some other VM
team that I either don't know or didn't have a clue should be included in
the conversation.


>
> >(My concern is that this isn't
> >reliable - we know from experience that other VMs can miss such
> >questions when they're mixed in with the rest of the python-dev
> >traffic)
> >
> >2. As 1, but we adopt a subject line convention to make it easier to
> >filter out general python-dev traffic for those that are just
> >interested in cross-vm questions
>
> +1
>

But that then requires new people to the list learn about this "magical"
convention. We already know people don't always read the intro paragraph to
the mailing list to say this is for development *of* Python, why do you
think this will be any better? The anti-top-posting happens only because
everyone replies inline so people just naturally follow that. I don't see
people remembering to use the magical subject line consistently. This would
also be the first time one has to set up a special email filtering rule for
python-dev to get a result that people are expected to have available to
them.


>
> >As Brett pointed out, it's similar to the resurrection of import-sig -
> >we know that decisions aren't final until they're resolved on
> >python-dev, but it also means we're not flooding python-dev with
> >interminable arcane discussions on import system internals.
>
> I personally already ignore much of python-dev and only chime in on
> subjects I
> both care about and delude myself into thinking I have something useful to
> contribute.  For cases where I miss something and need to catch up, Gmane
> is
> perfect.
>

But your search area of interest is probably quite larger than that for
other VM implementers. Being into VMs and compatibility <> into language
design which the bulk of python-dev is about (and yes, I used that
not-equals operator just for you, Barry, to get the point across =).
___
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] backporting stdlib 2.7.x from pypy to cpython

[Brett Cannon]

On Mon, Jun 11, 2012 at 3:35 PM, PJ Eby  wrote:

> On Mon, Jun 11, 2012 at 12:33 PM, Jeff Hardy  wrote:
>
>> On Mon, Jun 11, 2012 at 8:28 AM, Eric Snow 
>> wrote:
>> > Nick's option 2 would be an improvement, but I imagine that option 3
>> > would have been the most effective by far.  Of course, the key thing
>> > is how closely the various implementors would follow the new list.
>> > Only they could say, though Frank Wierzbicki seemed positive about it.
>>
>> This has come up a couple of times recently (discussions on PEP 421
>> and PEP 405), so I think it would be worth while. I don't have the
>> time to track all of the different proposals that are in flux; it
>> would be nice to know when they're "done" and just need a sanity check
>> to make sure everything will work for other implementations.
>>
>>
> Yes, perhaps if the list were *just* a place to cc: in or send a heads-up
> to python-dev discussions, and not to have actual list discussions per se,
> that would do the trick.
>
> IOW, the idea is, "If you're a contributor to a non-CPython
> implementation, subscribe here to get a heads-up on Python-Dev discussions
> you should be following."  Not, "here's a list to discuss Python
> implementations in general", and definitely not a place to *actually
> conduct discussions* at all: the only things ever posted there should be
> cc:'d from or to Python-Dev, or be pointers to Python-Dev threads.
>
>
Do you know how much of a pain that could become if you were moderator of
that list? Having to potentially clear every email that goes to some thread
by hand would become nearly unmanageable.


> That way, we'd have a solution for the periodic, "hmm, we should get other
> implementations to weigh in on this thread" problem, that wouldn't actually
> divide the discussion.  Instead, we'd have a "Bat Signal" (Snake Signal?)
> to bring the other heroes in to meet with Commissioner Guido.  ;-)
>

But we already have the various SIGs carry out discussions outside of
python-dev and just bring forward their results to python-dev when they are
ready. Why would this list be any different?
___
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] backporting stdlib 2.7.x from pypy to cpython

[Barry Warsaw]

On Jun 11, 2012, at 04:58 PM, Nick Coghlan wrote:

>1. Asking on python-dev is considered adequate. If an implementation
>wants to be consulted on changes, one or more of their developers
>*must* follow python-dev sufficiently closely that they don't miss
>cross-VM compatibility questions.

That's certainly my preference.

>(My concern is that this isn't
>reliable - we know from experience that other VMs can miss such
>questions when they're mixed in with the rest of the python-dev
>traffic)
>
>2. As 1, but we adopt a subject line convention to make it easier to
>filter out general python-dev traffic for those that are just
>interested in cross-vm questions

+1

>As Brett pointed out, it's similar to the resurrection of import-sig -
>we know that decisions aren't final until they're resolved on
>python-dev, but it also means we're not flooding python-dev with
>interminable arcane discussions on import system internals.

I personally already ignore much of python-dev and only chime in on subjects I
both care about and delude myself into thinking I have something useful to
contribute.  For cases where I miss something and need to catch up, Gmane is
perfect.

-Barry

___
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] backporting stdlib 2.7.x from pypy to cpython

[PJ Eby]

On Mon, Jun 11, 2012 at 12:33 PM, Jeff Hardy  wrote:

> On Mon, Jun 11, 2012 at 8:28 AM, Eric Snow 
> wrote:
> > Nick's option 2 would be an improvement, but I imagine that option 3
> > would have been the most effective by far.  Of course, the key thing
> > is how closely the various implementors would follow the new list.
> > Only they could say, though Frank Wierzbicki seemed positive about it.
>
> This has come up a couple of times recently (discussions on PEP 421
> and PEP 405), so I think it would be worth while. I don't have the
> time to track all of the different proposals that are in flux; it
> would be nice to know when they're "done" and just need a sanity check
> to make sure everything will work for other implementations.
>
>
Yes, perhaps if the list were *just* a place to cc: in or send a heads-up
to python-dev discussions, and not to have actual list discussions per se,
that would do the trick.

IOW, the idea is, "If you're a contributor to a non-CPython implementation,
subscribe here to get a heads-up on Python-Dev discussions you should be
following."  Not, "here's a list to discuss Python implementations in
general", and definitely not a place to *actually conduct discussions* at
all: the only things ever posted there should be cc:'d from or to
Python-Dev, or be pointers to Python-Dev threads.

That way, we'd have a solution for the periodic, "hmm, we should get other
implementations to weigh in on this thread" problem, that wouldn't actually
divide the discussion.  Instead, we'd have a "Bat Signal" (Snake Signal?)
to bring the other heroes in to meet with Commissioner 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] TZ-aware local time

[Guido van Rossum]

Let's agree to disagree. I don't have the time to argue any more but
you haven't convinced me.

On Mon, Jun 11, 2012 at 11:42 AM, Alexander Belopolsky
 wrote:
> On Mon, Jun 11, 2012 at 1:01 PM, Guido van Rossum  wrote:
> ..
>> Maybe the problem here is the *input*? It should be a POSIX timestamp,
>> not a datetime object.
>>
>
> No.  "Seconds since epoch" or "POSIX" timestamp is a foreign data type
> to the datetime module.  An aware datetime object with
> tzinfo=timezone.utc or a naive datetime object representing UTC time
> by convention is the datetime module way to represent absolute time.
> If I need to convert time obtained from an e-mail header or a log file
> to local time, I don't want to go through a  "POSIX" timestamp.  I
> want the obvious code to work correctly:
>
 t = datetime.strptime(time_string, format)
 local_time_string = datetime.localtime(t).strftime(format)
>
> (Note that the first statement already works in 3.2 if timezone
> information is compatible with %z format.)
>
> ..
>> Ok, I trust that LocalTimezone doesn't solve your problem. Separately,
>> then, I still think we should have it in the stdlib, since it probably
>> covers the most use cases besides the utc we already have.
>>
>
> I am not against adding LocalTimezone to datetime.  We can copy
> tzinfo-examples.py to datetime.py and call it the day.  However, this
> will not eliminate the need for the localtime() function.
>
>> PS. TBH I don't care for the idea that we should try to hide the time
>> module and consider it a low-level implementation detail for the shiny
>> high-level datetime module.
>
> I don't think I ever promoted this idea.  The time module has its
> uses, but ATM it does not completely solve the local time problem
> either.  See .
>
>> .. Users
>> should be required to understand POSIX timestamps and the importance
>> of UTC before they try to work with multiple timezones.
>
> I disagree.  First, UTC and POSIX timestamps are not the same thing.
> I am not talking about leap seconds or epoch.  I just find this:
>
> $ TZ=UTC date
> Mon Jun 11 18:15:48 UTC 2012
>
> much easier to explain than this:
>
> $ TZ=UTC date +%s
> 1339438586
>
> There is no need to expose developers of e-mail servers or log
> analytics to 9-10 digit integers or even longer floats.  Second, UTC
> is only special in the way that zero is special.  If you write a
> function converting incoming time string to local time, you don't need
> to special case UTC as long as incoming format includes explicit
> offset.
>
>> And they
>> should store timestamps as POSIX timestamps, not as datetime objects
>> with an (implicit or explicit) UTC timezone.
>
> I disagree again.  At the end of the day, they should "store"
> timestamps in a human-readable text format.  For example,
>
> http://www.w3.org/TR/xmlschema-2/#isoformats
>
> Users who want an object that stores a POSIX timestamp internally, but
> presents rich date-time interface can use an excellent mxDateTime
> class.
>
> It is one thing to provide datetime.fromtimestamp() and
> datetime.timestamp() methods for interoperability, it is quite another
> thing to require users to convert their datetime instances to
> timestamp for basic timezone operations.



-- 
--Guido van Rossum (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] TZ-aware local time

[Alexander Belopolsky]

On Mon, Jun 11, 2012 at 1:01 PM, Guido van Rossum  wrote:
..
> Maybe the problem here is the *input*? It should be a POSIX timestamp,
> not a datetime object.
>

No.  "Seconds since epoch" or "POSIX" timestamp is a foreign data type
to the datetime module.  An aware datetime object with
tzinfo=timezone.utc or a naive datetime object representing UTC time
by convention is the datetime module way to represent absolute time.
If I need to convert time obtained from an e-mail header or a log file
to local time, I don't want to go through a  "POSIX" timestamp.  I
want the obvious code to work correctly:

>>> t = datetime.strptime(time_string, format)
>>> local_time_string = datetime.localtime(t).strftime(format)

(Note that the first statement already works in 3.2 if timezone
information is compatible with %z format.)

..
> Ok, I trust that LocalTimezone doesn't solve your problem. Separately,
> then, I still think we should have it in the stdlib, since it probably
> covers the most use cases besides the utc we already have.
>

I am not against adding LocalTimezone to datetime.  We can copy
tzinfo-examples.py to datetime.py and call it the day.  However, this
will not eliminate the need for the localtime() function.

> PS. TBH I don't care for the idea that we should try to hide the time
> module and consider it a low-level implementation detail for the shiny
> high-level datetime module.

I don't think I ever promoted this idea.  The time module has its
uses, but ATM it does not completely solve the local time problem
either.  See .

> .. Users
> should be required to understand POSIX timestamps and the importance
> of UTC before they try to work with multiple timezones.

I disagree.  First, UTC and POSIX timestamps are not the same thing.
I am not talking about leap seconds or epoch.  I just find this:

$ TZ=UTC date
Mon Jun 11 18:15:48 UTC 2012

much easier to explain than this:

$ TZ=UTC date +%s
1339438586

There is no need to expose developers of e-mail servers or log
analytics to 9-10 digit integers or even longer floats.  Second, UTC
is only special in the way that zero is special.  If you write a
function converting incoming time string to local time, you don't need
to special case UTC as long as incoming format includes explicit
offset.

> And they
> should store timestamps as POSIX timestamps, not as datetime objects
> with an (implicit or explicit) UTC timezone.

I disagree again.  At the end of the day, they should "store"
timestamps in a human-readable text format.  For example,

http://www.w3.org/TR/xmlschema-2/#isoformats

Users who want an object that stores a POSIX timestamp internally, but
presents rich date-time interface can use an excellent mxDateTime
class.

It is one thing to provide datetime.fromtimestamp() and
datetime.timestamp() methods for interoperability, it is quite another
thing to require users to convert their datetime instances to
timestamp for basic timezone operations.
___
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] TZ-aware local time

[R. David Murray]

On Mon, 11 Jun 2012 10:01:57 -0700, Guido van Rossum  wrote:
> On Mon, Jun 11, 2012 at 6:33 AM, Alexander Belopolsky
>  wrote:
> > On Fri, Jun 8, 2012 at 11:06 PM, Guido van Rossum  wrote:
> >> On Fri, Jun 8, 2012 at 2:08 PM, Alexander Belopolsky
> >>  wrote:
> > ..
> >> t = mktime((2010, 11, 7, 1, 0, 0, -1, -1, 0))
> >> for i in range(5):
> >>> ...     print(strftime("%T%z", localtime(t + i - 2)))
> >>> ...
> >>> 01:59:58-0400
> >>> 01:59:59-0400
> >>> 01:00:00-0500
> >>> 01:00:01-0500
> >>> 01:00:02-0500
> >>>
> >>> As I explained at , it is not
> >>> possible to reproduce this sequence using LocalTimezone.
> >>
> >> So LocalTimezone (or any named timezone that uses DST) should not be
> >> used for this purpose.
> > ..
> >> I'm still unsure what problem you're trying to solve.
> >
> > The problem is: produce a timestamp (e.g.  RFC 3339) complete with
> > timezone information corresponding to the current time or any other
> > unambiguously defined time.  This is exactly what my proposed
> > datetime.localtime() function does.
> 
> Maybe the problem here is the *input*? It should be a POSIX timestamp,
> not a datetime object.
> 
> Another approach might be to tweak the existing timetuple() API to
> properly compute the is_dst flag? It currently always seems to return
> -1 for that flag.
> 
> >> Can we just
> >> introduce LocalTimezone (or whatever name it should have) and let the
> >> issue rest?
> >
> > No.  LocalTimezone adresses a different problem and does not solve
> > this one.  If you generate a timestamp using
> > datetime.now(LocalTimezone).strftime("... %z"), your timestamps will
> > be wrong for one hour every year.  Some users may tolerate this, but
> > the problem is not hard to solve and I think datetime module should
> > offer one obvious and correct way to do it.
> 
> Ok, I trust that LocalTimezone doesn't solve your problem. Separately,
> then, I still think we should have it in the stdlib, since it probably
> covers the most use cases besides the utc we already have.
> 
> PS. TBH I don't care for the idea that we should try to hide the time
> module and consider it a low-level implementation detail for the shiny
> high-level datetime module. The simply serve different purposes. Users
> should be required to understand POSIX timestamps and the importance
> of UTC before they try to work with multiple timezones. And they
> should store timestamps as POSIX timestamps, not as datetime objects
> with an (implicit or explicit) UTC timezone.

For 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
obtained from other email headers.  An aware timezone using a 'timezone'
tzinfo object seems the most logical thing to use for that, which means
I need a way to go from 'now' to such a datetime object.

I don't care how it happens :)

--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

Re: [Python-Dev] TZ-aware local time

[Guido van Rossum]

On Mon, Jun 11, 2012 at 6:33 AM, Alexander Belopolsky
 wrote:
> On Fri, Jun 8, 2012 at 11:06 PM, Guido van Rossum  wrote:
>> On Fri, Jun 8, 2012 at 2:08 PM, Alexander Belopolsky
>>  wrote:
> ..
>> t = mktime((2010, 11, 7, 1, 0, 0, -1, -1, 0))
>> for i in range(5):
>>> ...     print(strftime("%T%z", localtime(t + i - 2)))
>>> ...
>>> 01:59:58-0400
>>> 01:59:59-0400
>>> 01:00:00-0500
>>> 01:00:01-0500
>>> 01:00:02-0500
>>>
>>> As I explained at , it is not
>>> possible to reproduce this sequence using LocalTimezone.
>>
>> So LocalTimezone (or any named timezone that uses DST) should not be
>> used for this purpose.
> ..
>> I'm still unsure what problem you're trying to solve.
>
> The problem is: produce a timestamp (e.g.  RFC 3339) complete with
> timezone information corresponding to the current time or any other
> unambiguously defined time.  This is exactly what my proposed
> datetime.localtime() function does.

Maybe the problem here is the *input*? It should be a POSIX timestamp,
not a datetime object.

Another approach might be to tweak the existing timetuple() API to
properly compute the is_dst flag? It currently always seems to return
-1 for that flag.

>> Can we just
>> introduce LocalTimezone (or whatever name it should have) and let the
>> issue rest?
>
> No.  LocalTimezone adresses a different problem and does not solve
> this one.  If you generate a timestamp using
> datetime.now(LocalTimezone).strftime("... %z"), your timestamps will
> be wrong for one hour every year.  Some users may tolerate this, but
> the problem is not hard to solve and I think datetime module should
> offer one obvious and correct way to do it.

Ok, I trust that LocalTimezone doesn't solve your problem. Separately,
then, I still think we should have it in the stdlib, since it probably
covers the most use cases besides the utc we already have.

PS. TBH I don't care for the idea that we should try to hide the time
module and consider it a low-level implementation detail for the shiny
high-level datetime module. The simply serve different purposes. Users
should be required to understand POSIX timestamps and the importance
of UTC before they try to work with multiple timezones. And they
should store timestamps as POSIX timestamps, not as datetime objects
with an (implicit or explicit) UTC timezone.

-- 
--Guido van Rossum (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] backporting stdlib 2.7.x from pypy to cpython

[Jeff Hardy]

On Mon, Jun 11, 2012 at 8:28 AM, Eric Snow  wrote:
> Nick's option 2 would be an improvement, but I imagine that option 3
> would have been the most effective by far.  Of course, the key thing
> is how closely the various implementors would follow the new list.
> Only they could say, though Frank Wierzbicki seemed positive about it.

This has come up a couple of times recently (discussions on PEP 421
and PEP 405), so I think it would be worth while. I don't have the
time to track all of the different proposals that are in flux; it
would be nice to know when they're "done" and just need a sanity check
to make sure everything will work for other implementations.

- Jeff
___
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] backporting stdlib 2.7.x from pypy to cpython

[Alex Gaynor]

Eric Snow  gmail.com> writes:

> 
> Nick's option 2 would be an improvement, but I imagine that option 3
> would have been the most effective by far.  Of course, the key thing
> is how closely the various implementors would follow the new list.
> Only they could say, though Frank Wierzbicki seemed positive about it.

> -eric
> 


I'm +1 on such a list, I don't have the time to follow every single thread on
python-dev, and I'm sure I miss a lot of things, have a dedicated place for
things I know are relevant to my work would be a great help.

Alex

___
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] backporting stdlib 2.7.x from pypy to cpython

[Eric Snow]

On Mon, Jun 11, 2012 at 12:58 AM, Nick Coghlan  wrote:
> On Mon, Jun 11, 2012 at 11:29 AM, Guido van Rossum  wrote:
>> But what guarantee do you have that (a) the right people sign up for
>> the new list, and (b) topics are correctly brought up there instead of
>> on python-dev? I agree that python-dev is turning into a firehose, but
>> I am reluctant to create backwaters where people might arrive at what
>> they think is a consensus only because the important opinions aren't
>> represented there.
>
> If that's a concern, I'd be happy to limit the use of the new list to
> "Input from other implementations needed on python-dev thread ".
>
> At the moment, it's a PITA to chase other implementations to get
> confirmation that they can cope with a change we're considering, so
> I'd like confirmation that either:
>
> 1. Asking on python-dev is considered adequate. If an implementation
> wants to be consulted on changes, one or more of their developers
> *must* follow python-dev sufficiently closely that they don't miss
> cross-VM compatibility questions. (My concern is that this isn't
> reliable - we know from experience that other VMs can miss such
> questions when they're mixed in with the rest of the python-dev
> traffic)
> 2. As 1, but we adopt a subject line convention to make it easier to
> filter out general python-dev traffic for those that are just
> interested in cross-vm questions
> 3. Create a separate list for cross-VM discussions, *including*
> discussions that aren't directly relevant to Python-the-language or
> CPython-the-reference-interpreter (e.g. collaborating on a shared
> standard library fork). python-dev threads may be advertised on the
> new list if cross-VM feedback is considered particularly necessary.
>
> As Brett pointed out, it's similar to the resurrection of import-sig -
> we know that decisions aren't final until they're resolved on
> python-dev, but it also means we're not flooding python-dev with
> interminable arcane discussions on import system internals.

+1

While soliciting feedback on PEP 421 (sys.implementation), the first
option got me nearly no responses from the other major Python
implementations.  In the end, I tracked down which would be the
appropriate mailing lists for PyPy, Jython, and IronPython, and
directly wrote to them, which seemed a less than optimal approach.  It
also means that I left out any other interested parties.  As well, I'm
still not positive I wrote to the best lists for those
implementations.

Nick's option 2 would be an improvement, but I imagine that option 3
would have been the most effective by far.  Of course, the key thing
is how closely the various implementors would follow the new list.
Only they could say, though Frank Wierzbicki seemed positive about it.

FWIW, I also like Nick's idea of "redirecting" to ongoing python-dev
threads and his comparison of the proposed new list to import-sig.

-eric
___
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] TZ-aware local time

[Alexander Belopolsky]

On Fri, Jun 8, 2012 at 11:06 PM, Guido van Rossum  wrote:
> On Fri, Jun 8, 2012 at 2:08 PM, Alexander Belopolsky
>  wrote:
..
> t = mktime((2010, 11, 7, 1, 0, 0, -1, -1, 0))
> for i in range(5):
>> ...     print(strftime("%T%z", localtime(t + i - 2)))
>> ...
>> 01:59:58-0400
>> 01:59:59-0400
>> 01:00:00-0500
>> 01:00:01-0500
>> 01:00:02-0500
>>
>> As I explained at , it is not
>> possible to reproduce this sequence using LocalTimezone.
>
> So LocalTimezone (or any named timezone that uses DST) should not be
> used for this purpose.
..
> I'm still unsure what problem you're trying to solve.

The problem is: produce a timestamp (e.g.  RFC 3339) complete with
timezone information corresponding to the current time or any other
unambiguously defined time.  This is exactly what my proposed
datetime.localtime() function does.

> Can we just
> introduce LocalTimezone (or whatever name it should have) and let the
> issue rest?

No.  LocalTimezone adresses a different problem and does not solve
this one.  If you generate a timestamp using
datetime.now(LocalTimezone).strftime("... %z"), your timestamps will
be wrong for one hour every year.  Some users may tolerate this, but
the problem is not hard to solve and I think datetime module should
offer one obvious and correct way to do it.
___
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] VS 11 Express is Metro only.

[Jesse Noller]

On Friday, June 8, 2012 at 3:01 PM, Meador Inge wrote:

> On Fri, May 25, 2012 at 7:06 AM,  (mailto:mar...@v.loewis.de)> wrote:
> 
> > I hereby predict that Microsoft will revert this decision, and that VS
> > Express
> > 11 will be able to build CPython.
> 
> 
> 
> And your prediction was right on :-) :
> http://blogs.msdn.com/b/visualstudio/archive/2012/06/08/visual-studio-express-2012-for-windows-desktop.aspx.
> 
Martin's predictions are sometimes eerily correct. ;) 


___
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] backporting stdlib 2.7.x from pypy to cpython

[Nick Coghlan]

On Mon, Jun 11, 2012 at 11:29 AM, Guido van Rossum  wrote:
> But what guarantee do you have that (a) the right people sign up for
> the new list, and (b) topics are correctly brought up there instead of
> on python-dev? I agree that python-dev is turning into a firehose, but
> I am reluctant to create backwaters where people might arrive at what
> they think is a consensus only because the important opinions aren't
> represented there.

If that's a concern, I'd be happy to limit the use of the new list to
"Input from other implementations needed on python-dev thread ".

At the moment, it's a PITA to chase other implementations to get
confirmation that they can cope with a change we're considering, so
I'd like confirmation that either:

1. Asking on python-dev is considered adequate. If an implementation
wants to be consulted on changes, one or more of their developers
*must* follow python-dev sufficiently closely that they don't miss
cross-VM compatibility questions. (My concern is that this isn't
reliable - we know from experience that other VMs can miss such
questions when they're mixed in with the rest of the python-dev
traffic)
2. As 1, but we adopt a subject line convention to make it easier to
filter out general python-dev traffic for those that are just
interested in cross-vm questions
3. Create a separate list for cross-VM discussions, *including*
discussions that aren't directly relevant to Python-the-language or
CPython-the-reference-interpreter (e.g. collaborating on a shared
standard library fork). python-dev threads may be advertised on the
new list if cross-VM feedback is considered particularly necessary.

As Brett pointed out, it's similar to the resurrection of import-sig -
we know that decisions aren't final until they're resolved on
python-dev, but it also means we're not flooding python-dev with
interminable arcane discussions on import system internals.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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