Re: [Python-Dev] PEP: New timestamp formats
On 2 February 2012 03:47, Nick Coghlan ncogh...@gmail.com wrote: Rather than being timestamp specific, such a protocol would be a general numeric protocol. If (integer, numerator, denominator) is used (i.e. a mixed number in mathematical terms), then __from_mixed__ would be an appropriate name. If (integer, fractional, exponent) is used (i.e. a fixed point notation), then __from_fixed__ would work. # Algorithm for a from mixed numbers protocol, assuming division doesn't lose precision... def __from_mixed__(cls, integer, numerator, denominator): return cls(integer) + cls(numerator) / cls(denominator) # Algorithm for a from fixed point protocol, assuming negative exponents don't lose precision... def __from_fixed__(cls, integer, mantissa, base, exponent): return cls(integer) + cls(mantissa) * cls(base) ** cls(exponent) From a *usage* point of view, this idea is actually the same as the proposal currently in the PEP. The difference is that instead of adding custom support for a few particular types directly to time and os, it instead defines a more general purpose protocol that covers not only this use case, but also any other situation where high precision fractions are relevant. One interesting question with a named protocol approach is whether such a protocol should *require* explicit support, or if it should fall back to the underlying mathematical operations. Since the conversions to float and int in the timestamp case are already known to be lossy, permitting lossy conversion via the mathematical equivalents seems reasonable, suggesting possible protocol definitions as follows: # Algorithm for a potentially precision-losing from mixed numbers protocol def from_mixed(cls, integer, numerator, denominator): try: factory = cls.__from_mixed__ except AttributeError: return cls(integer) + cls(numerator) / cls(denominator) return factory(integer, numerator, denominator) # Algorithm for a potentially lossy from fixed point protocol def from_fixed(cls, integer, mantissa, base, exponent): try: factory = cls.__from_fixed__ except AttributeError: return cls(integer) + cls(mantissa) * cls(base) ** cls(exponent) return factory(integer, mantissa, base, exponent) The key problem with a protocol is that the implementer has to make these decisions. The callback approach defers that decision to the end user. After all, the end user is the one who knows for his app whether precision loss is acceptable. You could probably also have a standard named protocol which can be used as a callback in straightforward cases time.time(callback=timedelta.__from_mixed__) That's wordy, and a bit ugly, though. The callback code could special-case types and look for __from_mixed__, I guess. Or use an ABC, and have the code that uses the callback do if issubclass(cb, MixedNumberABC): return cb.__from_mixed__(whole, num, den) else: return cb(whole, num, den) (The second branch is the one that allows the user to override the predefined types that work - if you omit that, you're back to a named protocol and ABCs don't gain you much beyond documentation). Part of me feels that there's a use case for generic functions in here, but maybe not (as it's overloading on the return type). Let's not open that discussion again, though. Paul. ___ 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] A new dictionary implementation
On 01/02/2012 17:50, Guido van Rossum wrote: Another question: a common pattern is to use (immutable) class variables as default values for instance variables, and only set the instance variables once they need to be different. Does such a class benefit from your improvement? A less common pattern, but which still needs to work, is where a mutable class variable is deliberately store state across all instances of a class... Chris -- Simplistix - Content Management, Batch Processing Python Consulting - http://www.simplistix.co.uk ___ 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] PEP: New timestamp formats
I'd add datetime.timedelta to this list. It's exactly what timestamps
are, after all - the difference between the current time and the
relevant epoch value.
Ah yes, I forgot to mention it, whereas it is listed in the final
timestamp formats list :-)
* a) (sec, nsec): C timespec structure, useful for os.futimens() for example
* b) (sec, floatpart, exponent): value = sec + floatpart * 10**exponent
* c) (sec, floatpart, divisor): value = sec + floatpart / divisor
The format (a) and (b) may loose precision if the clock divisor is not a
power of 10.
Format (b) only loses precision if the exponent chosen for a given
value is too small relative to the precision of the underlying timer
(it's the same as using decimal.Decimal in that respect).
Let's take an NTP timestamp in format (c): (sec=0,
floatpart=1, divisor=2**32):
Decimal(1) * Decimal(10)**-10
Decimal('0.01')
Decimal(1) / Decimal(2)**32
Decimal('0.023283064365386962890625')
You have an error of 57%. Or do you mean that not only 2**32 should be
modified, but also 1? How do you adapt 1 (floatpart)
when changing the divisor (2**32 = 10**-10)? The format (c) avoids an
operation (base^exponent) and avoids loosing precision.
There is the same issue with QueryPerformanceFrequency and
QueryPerformanceCounter used by time.clock(), the frequency is not a
power of any base.
I forgot to mention another advantage of (c), used by my patch for the
Decimal format: you can get the exact resolution of the clock
directly: 1/divisor. It works for any divisor (not only
base^exponent).
By the way, the format (c) can be simplified as a fraction:
(numerator, denominator) using (seconds * divisor + floatpart,
divisor). But this format is less practical to implement a function
creating a timestamp.
Callback and creating a new module to convert timestamps
(...)
Such an API could only become limiting if
timestamps ever become something other than the difference in time
between right now and the relevant epoch value, and that's a
sufficiently esoteric possibility that it really doesn't seem
worthwhile to take it into account.
It may be interesting to support a different start date (other than
1970.1.1), if we choose to support broken-down timestamps (e.g.
datetime.datetime).
The PEP should also mention PJE's suggestion of creating a new named
protocol specifically for the purpose (with a signature based on one
of the proposed tuple formats) (...)
Ok, I will add it.
Rather than being timestamp specific, such a protocol would be a
general numeric protocol. If (integer, numerator, denominator) is used
(i.e. a mixed number in mathematical terms), then __from_mixed__
would be an appropriate name. If (integer, fractional, exponent) is
used (i.e. a fixed point notation), then __from_fixed__ would work.
# Algorithm for a from mixed numbers protocol, assuming division
doesn't lose precision...
def __from_mixed__(cls, integer, numerator, denominator):
return cls(integer) + cls(numerator) / cls(denominator)
Even if I like the idea, I don't think that we need all this machinery
to support nanosecond resolution. I should maybe forget my idea of
using datetime.datetime or datetime.timedelta, or only only support
int, float and decimal.Decimal.
datetime.datetime and datetime.timedelta are already compatible with
Decimal (except that they may loose precision because of an internal
conversion to float): datetime.datetime.fromtimestamp(t) and
datetime.timedelta(seconds=t).
If we only support int, float and Decimal, we don't need to add a new
protocol, hardcoded functions are enough :-)
os.stat: add new fields
---
It was proposed to add 3 fields to os.stat() structure to get nanoseconds of
timestamps.
It's worth noting that the challenge with this is that it's
potentially time consuming to populating the extra fields, and that
this approach doesn't help with the time APIs that return timestamps
directly.
New fields can be optional (add a flag to get them), but I don't like
the idea of a structure with a variable number of fields, especially
because os.stat() structure can be used as a tuple (get a field by its
index).
Patching os.stat() doesn't solve the problem for the time module anyway.
Add an argument to change the result type
-
There should also be a description of the set a boolean flag to
request high precision output approach.
You mean something like: time.time(hires=True)? Or time.time(decimal=True)?
Victor
___
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] PEP: New timestamp formats
On 2 February 2012 12:16, Victor Stinner victor.stin...@haypocalc.com wrote:
Let's take an NTP timestamp in format (c): (sec=0,
floatpart=1, divisor=2**32):
Decimal(1) * Decimal(10)**-10
Decimal('0.01')
Decimal(1) / Decimal(2)**32
Decimal('0.023283064365386962890625')
You have an error of 57%. Or do you mean that not only 2**32 should be
modified, but also 1? How do you adapt 1 (floatpart)
when changing the divisor (2**32 = 10**-10)? The format (c) avoids an
operation (base^exponent) and avoids loosing precision.
Am I missing something? If you're using the fixed point form
(fraction, exponent) then 0.023283064365386962890625 would be written
as (23283064365386962890625, -23). Same precision as the (1,
base=2, exponent=32) format.
Confused,
Paul
___
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] PEP: New timestamp formats
On Thu, Feb 2, 2012 at 10:16 PM, Victor Stinner victor.stin...@haypocalc.com wrote: If we only support int, float and Decimal, we don't need to add a new protocol, hardcoded functions are enough :-) Yup, that's why your middle-ground approach didn't make any sense to me. Returning Decimal when a flag is set to request high precision values actually handles everything (since any epoch related questions only arise later when converting the decimal timestamp to an absolute time value). I think a protocol based approach would be *feasible*, but also overkill for the specific problem we're trying to handle (i.e. arbitrary precision timestamps). If a dependency from time and os on the decimal module means we decide to finally incorporate Stefan's cdecimal branch, I consider that a win in its own right (there are some speed hacks in decimal that didn't fair well in the Py3k transition because they went from being 8-bit str based to Unicode str based. They didn't *break* from a correctness point of view, but my money would be on they're being pessimisations now instead of optimisations). os.stat: add new fields --- New fields can be optional (add a flag to get them), but I don't like the idea of a structure with a variable number of fields, especially because os.stat() structure can be used as a tuple (get a field by its index). Patching os.stat() doesn't solve the problem for the time module anyway. We can't add new fields to the stat tuple anyway - it breaks tuple unpacking. Any new fields would have been accessible by name only (which poses its own problems, but is a solution we've used before - in the codecs module, for example). As you say though, this was never going to be adequate since it doesn't help with the time APIs. Add an argument to change the result type - There should also be a description of the set a boolean flag to request high precision output approach. You mean something like: time.time(hires=True)? Or time.time(decimal=True)? Yeah, I was thinking hires as the short form of high resolution, but it's a little confusing since it also parses as the word hires (i.e. hire+s). hi_res, hi_prec (for high precision) or full_prec (for full precision) might be better. I don't really like decimal as the flag name, since it confuses an implementation detail (using decimal.Decimal) with the design intent (preserving the full precision of the underlying timestamp). 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] PEP: New timestamp formats
Even if I like the idea, I don't think that we need all this machinery to support nanosecond resolution. I should maybe forget my idea of using datetime.datetime or datetime.timedelta, or only only support int, float and decimal.Decimal. I updated my patch (issue #13882) to only support int, float and decimal.Decimal types. I suppose that it is just enough. Only adding decimal.Decimal type avoids many questions: - which API / protocol should be used to support other types - what is the start of a timestamp? - etc. As we seen: using time.time(timestamp=type) API, it will be easy to support new types later (using a new protocol, a registry like Unicode codecs, or anything else). Let's start with decimal.Decimal and support it correctly (e.g. patch datetime.datetime.fromtimestamp() and os.*utime*() functions). Victor ___ 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] PEP: New timestamp formats
On Thu, Feb 2, 2012 at 10:45 PM, Paul Moore p.f.mo...@gmail.com wrote:
On 2 February 2012 12:16, Victor Stinner victor.stin...@haypocalc.com wrote:
Let's take an NTP timestamp in format (c): (sec=0,
floatpart=1, divisor=2**32):
Decimal(1) * Decimal(10)**-10
Decimal('0.01')
Decimal(1) / Decimal(2)**32
Decimal('0.023283064365386962890625')
You have an error of 57%. Or do you mean that not only 2**32 should be
modified, but also 1? How do you adapt 1 (floatpart)
when changing the divisor (2**32 = 10**-10)? The format (c) avoids an
operation (base^exponent) and avoids loosing precision.
Am I missing something? If you're using the fixed point form
(fraction, exponent) then 0.023283064365386962890625 would be written
as (23283064365386962890625, -23). Same precision as the (1,
base=2, exponent=32) format.
Yeah, Victor's persuaded me that the only two integer based formats
that would be sufficiently flexible are (integer, numerator, divisor)
and (integer, mantissa, base, exponent). The latter allows for a few
more optimised conversions in particular cases. Assuming a base of 10
would just make things unnecessarily awkward when the underlying base
is 2, though.
However, I think it's even more right to not have a protocol at all
and just use decimal.Decimal for arbitrary precision timestamps
(explicitly requested via a flag to preserve backwards compatibility).
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] PEP: New timestamp formats
On Thu, Feb 2, 2012 at 11:10 PM, Victor Stinner victor.stin...@haypocalc.com wrote: Even if I like the idea, I don't think that we need all this machinery to support nanosecond resolution. I should maybe forget my idea of using datetime.datetime or datetime.timedelta, or only only support int, float and decimal.Decimal. I updated my patch (issue #13882) to only support int, float and decimal.Decimal types. I suppose that it is just enough. Only adding decimal.Decimal type avoids many questions: - which API / protocol should be used to support other types - what is the start of a timestamp? - etc. As we seen: using time.time(timestamp=type) API, it will be easy to support new types later (using a new protocol, a registry like Unicode codecs, or anything else). Yeah, I can definitely live with the type-based API if we restrict it to those 3 types. 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] PEP: New timestamp formats
On Thu, 2 Feb 2012 23:07:28 +1000 Nick Coghlan ncogh...@gmail.com wrote: We can't add new fields to the stat tuple anyway - it breaks tuple unpacking. I don't think that's true. The stat tuple already has a varying number of fields: http://docs.python.org/dev/library/os.html#os.stat “For backward compatibility, the return value of stat() is also accessible as a tuple of *at least* 10 integers [...] More items may be added at the end by some implementations.” (emphasis mine) So at most you could tuple-unpack os.stat(...)[:10]. (I've never seen code tuple-unpacking a stat tuple, myself. It sounds quite cumbersome to do so.) Add an argument to change the result type - There should also be a description of the set a boolean flag to request high precision output approach. You mean something like: time.time(hires=True)? Or time.time(decimal=True)? Yeah, I was thinking hires as the short form of high resolution, but it's a little confusing since it also parses as the word hires (i.e. hire+s). hi_res, hi_prec (for high precision) or full_prec (for full precision) might be better. I don't really like decimal as the flag name, since it confuses an implementation detail (using decimal.Decimal) with the design intent (preserving the full precision of the underlying timestamp). But that implementation detail will be visible to the user, including when combining the result with other numbers (as Decimal wins over float and int). IMHO it wouldn't be silly to make it explicit. I think hires may confuse people into thinking the time source has a higher resolution, whereas it's only the return type. Perhaps it's just a documentation issue, though. Regards Antoine. ___ 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] PEP: New timestamp formats
On Thu, 2 Feb 2012 14:10:14 +0100 Victor Stinner victor.stin...@haypocalc.com wrote: Even if I like the idea, I don't think that we need all this machinery to support nanosecond resolution. I should maybe forget my idea of using datetime.datetime or datetime.timedelta, or only only support int, float and decimal.Decimal. I updated my patch (issue #13882) to only support int, float and decimal.Decimal types. I suppose that it is just enough. Why int? That doesn't seem to bring anything. Regards Antoine. ___ 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] PEP: New timestamp formats
Nick Coghlan wrote: On Thu, Feb 2, 2012 at 10:16 PM, Victor Stinner Add an argument to change the result type - There should also be a description of the set a boolean flag to request high precision output approach. You mean something like: time.time(hires=True)? Or time.time(decimal=True)? Yeah, I was thinking hires as the short form of high resolution, but it's a little confusing since it also parses as the word hires (i.e. hire+s). hi_res, hi_prec (for high precision) or full_prec (for full precision) might be better. Isn't the above (having the return type depend on an argument setting) something we generally try to avoid ? I think it's better to settle on one type for high-res timers and add a new API(s) for it. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Feb 02 2012) Python/Zope Consulting and Support ...http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try our new mxODBC.Connect Python Database Interface for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ 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] PEP: New timestamp formats
On Thu, Feb 2, 2012 at 11:31 PM, M.-A. Lemburg m...@egenix.com wrote: Isn't the above (having the return type depend on an argument setting) something we generally try to avoid ? In Victor's actual patch, the returned object is an instance of the type you pass in, so it actually avoids that issue. I think it's better to settle on one type for high-res timers and add a new API(s) for it. We've basically settled on decimal.Decimal now, so yeah, the decision becomes one of spelling - either new APIs that always return Decimal instances, or a way to ask the existing APIs to return Decimal instead of floats. The way I see it, the latter should be significantly less hassle to maintain (since the code remains almost entirely shared), and it becomes trivial for someone to layer a convenience wrapper over the top that *always* requests the high precision output. 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] PEP: New timestamp formats
Why int? That doesn't seem to bring anything. It helps to deprecate/replace os.stat_float_times(), which may be used for backward compatibility (with Python 2.2 ? :-)). ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP: New timestamp formats
On Thu, 2 Feb 2012 15:09:41 +0100 Victor Stinner victor.stin...@haypocalc.com wrote: Why int? That doesn't seem to bring anything. It helps to deprecate/replace os.stat_float_times(), which may be used for backward compatibility (with Python 2.2 ? :-)). I must admit I don't understand the stat_float_times documentation: “For compatibility with older Python versions, accessing stat_result as a tuple always returns integers. Python now returns float values by default. Applications which do not work correctly with floating point time stamps can use this function to restore the old behaviour.” These two paragraphs seem to contradict themselves. That said, I don't understand why we couldn't simply deprecate stat_float_times() right now. Having an option for integer timestamps is pointless, you can just call int() on the result if you want. Regards Antoine. ___ 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] PEP: New timestamp formats
That said, I don't understand why we couldn't simply deprecate stat_float_times() right now. Having an option for integer timestamps is pointless, you can just call int() on the result if you want. So which API do you propose for time.time() to get a Decimal object? time.time(timestamp=decimal.Decimal) time.time(decimal=True) or time.time(hires=True) or something else? Victor ___ 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] PEP: New timestamp formats
On Feb 02, 2012, at 11:07 PM, Nick Coghlan wrote: Yup, that's why your middle-ground approach didn't make any sense to me. Returning Decimal when a flag is set to request high precision values actually handles everything (since any epoch related questions only arise later when converting the decimal timestamp to an absolute time value). Guido really dislikes APIs where a flag changes the return type, and I agree with him. It's because this is highly unreadable: results = blah.whatever(True) What the heck does that `True` do? It can be marginally better with a keyword-only argument, but not much. I haven't read the whole thread so maybe this is a stupid question, but why can't we add a datetime-compatible higher precision type that hides all the implementation details? -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] A new dictionary implementation
On 02/02/2012 11:30, Chris Withers wrote: On 01/02/2012 17:50, Guido van Rossum wrote: Another question: a common pattern is to use (immutable) class variables as default values for instance variables, and only set the instance variables once they need to be different. Does such a class benefit from your improvement? A less common pattern, but which still needs to work, is where a mutable class variable is deliberately store state across all instances of a class... Given that Mark's patch passes the Python test suite I'm sure basic patterns like this *work*, the question is which of them take advantage of the improved memory efficiency. In the case you mention I don't think it's an issue at all, because the class level attribute doesn't (generally) appear in instance dicts. What's also common is where the class holds a *default* value for instances, which may be overridden by an instance attribute on *some* instances. All the best, Michael Foord Chris -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ 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] A new dictionary implementation
On Wed, 1 Feb 2012 09:50:55 -0800 Guido van Rossum gu...@python.org wrote: On Wed, Feb 1, 2012 at 9:13 AM, Hans Mulder han...@xs4all.nl wrote: On 30/01/12 00:30:14, Steven D'Aprano wrote: Mark Shannon wrote: Antoine Pitrou wrote: [..] Antoine is right. It is a reorganisation of the dict, plus a couple of changes to typeobject.c and object.c to ensure that instance dictionaries do indeed share keys arrays. I don't quite follow how that could work. If I have this: class C: pass a = C() b = C() a.spam = 1 b.ham = 2 how can a.__dict__ and b.__dict__ share key arrays? I've tried reading the source, but I'm afraid I don't understand it well enough to make sense of it. They can't. But then, your class is atypical. Usually, classes initialize all the attributes of their instances in the __init__ method, perhaps like so: class D: def __init__(self, ham=None, spam=None): self.ham = ham self.spam = spam As long as you follow the common practice of not adding any attributes after the object has been initialized, your instances can share their keys array. Mark's patch will do that. You'll still be allowed to have different attributes per instance, but if you do that, then the patch doesn't buy you much. Hey, I like this! It's a subtle encouragement for developers to initialize all their instance variables in their __init__ or __new__ method, with a (modest) performance improvement for a carrot. (Though I have to admit I have no idea how you do it. Wouldn't the set of dict keys be different while __init__ is in the middle of setting the instance variables?) Another question: a common pattern is to use (immutable) class variables as default values for instance variables, and only set the instance variables once they need to be different. Does such a class benefit from your improvement? I'm not sure who you is in your e-mail, but AFAICT Mark's patch doesn't special-case __init__ or __new__. Any attribute setting on an instance uses the shared keys array on the instance's type. Missing attributes on an instance are simply NULL pointers in the instance's values array. (I've suggested that the keys array be bounded in size, to avoid pathological cases where someone (ab)uses instances as fancy dicts and puts lots of random data in them) Regards Antoine. ___ 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] A new dictionary implementation
Am 02.02.2012 12:30, schrieb Chris Withers: On 01/02/2012 17:50, Guido van Rossum wrote: Another question: a common pattern is to use (immutable) class variables as default values for instance variables, and only set the instance variables once they need to be different. Does such a class benefit from your improvement? A less common pattern, but which still needs to work, is where a mutable class variable is deliberately store state across all instances of a class... This is really *just* a dictionary implementation. It doesn't affect any of the lookup procedures. If you trust that the dictionary semantics on its own isn't changed (which I believe is the case, except for key order), none of the dict applications will change. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] A new dictionary implementation
Just a quick update. I've been analysing and profile the behaviour of my new dict and messing about with various implementation options. I've settled on a new implementation. Its the same basic idea, but with better locality of reference for unshared keys. Guido asked: Another question: a common pattern is to use (immutable) class variables as default values for instance variables, and only set the instance variables once they need to be different. Does such a class benefit from your improvement? For those instances which keep the default, yes. Otherwise the answer is, as Martin pointed out, it could yes provided that adding a new key does not force a resize. Although it is a bit arbitrary when a resize occurs. The new version will incorporate this behaviour. Expect version 2 soon. Cheers, Mark. ___ 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] PEP: New timestamp formats
On Feb 3, 2012 2:59 AM, Barry Warsaw ba...@python.org wrote: On Feb 02, 2012, at 11:07 PM, Nick Coghlan wrote: Yup, that's why your middle-ground approach didn't make any sense to me. Returning Decimal when a flag is set to request high precision values actually handles everything (since any epoch related questions only arise later when converting the decimal timestamp to an absolute time value). Guido really dislikes APIs where a flag changes the return type, and I agree with him. It's because this is highly unreadable: results = blah.whatever(True) What the heck does that `True` do? It can be marginally better with a keyword-only argument, but not much. Victor's patch passes in the return type rather than a binary flag, thus avoiding this particular problem. I haven't read the whole thread so maybe this is a stupid question, but why can't we add a datetime-compatible higher precision type that hides all the implementation details? -Barry It's not a stupid question, but for backwards compatibility, what we would actually need is a version of Decimal that implicitly interoperates with binary floats. That's... not trivial. Cheers, Nick -- Sent from my phone, thus the relative brevity :) ___ 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] PEP: New timestamp formats
On Wed, Feb 1, 2012 at 5:03 PM, Victor Stinner victor.stin...@haypocalc.com wrote: datetime.datetime - datetime.datetime only supports microsecond resolution, but can be enhanced to support nanosecond. datetime.datetime has issues: - there is no easy way to convert it into seconds since the epoch Not true: import datetime, time epoch = datetime.datetime(1970, 1, 1, 0, 0, 0) (datetime.datetime.utcnow() - epoch).total_seconds() 1328219742.385039 time.time() 1328219747.640937 - any broken-down time has issues of time stamp ordering in the duplicate hour of switching from DST to normal time Only if you insist on putting it in a timezone. Use UTC, and you should be fine. - time zone support is flaky-to-nonexistent in the datetime module Why do you need time zone support for system interfaces that return times in UTC? I think I saw another objection that datetime represented points in time, while functions like time.time() and os.stat() return an offset from the epoch. This objection seems silly to me: the return value of the system interfaces intends to represent points in time, even though it has to be implemented as an offset since an epoch because of limitations in C, and datetime is also implemented as an offset from an epoch (year 0). On the other hand, the return value of functions like time.clock() is _not_ intended to represent an exact point in time, and so should be either a timedelta or Decimal. Jeffrey ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3 optimizations, continued, continued again...
On Wed, Feb 1, 2012 at 20:08, stefan brunthaler s.bruntha...@uci.edu wrote: I understand all of these issues. Currently, it's not really a mess, but much more complicated as it needs to be for only supporting the inca optimization. I really don't think that is a problem. The core contributors can deal well with complexity in my experience. :-) //Lennart ___ 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] PEP 409 update [was: PEP 409 - final?]
PEP: 409 Title: Suppressing exception context Version: $Revision$ Last-Modified: $Date$ Author: Ethan Furman et...@stoneleaf.us Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 26-Jan-2012 Post-History: 30-Aug-2002, 01-Feb-2012, 03-Feb-2012 Abstract One of the open issues from PEP 3134 is suppressing context: currently there is no way to do it. This PEP proposes one. Rationale = There are two basic ways to generate exceptions: 1) Python does it (buggy code, missing resources, ending loops, etc.) 2) manually (with a raise statement) When writing libraries, or even just custom classes, it can become necessary to raise exceptions; moreover it can be useful, even necessary, to change from one exception to another. To take an example from my dbf module: try: value = int(value) except Exception: raise DbfError(...) Whatever the original exception was (/ValueError/, /TypeError/, or something else) is irrelevant. The exception from this point on is a /DbfError/, and the original exception is of no value. However, if this exception is printed, we would currently see both. Alternatives Several possibilities have been put forth: * /raise as NewException()/ Reuses the /as/ keyword; can be confusing since we are not really reraising the originating exception * /raise NewException() from None/ Follows existing syntax of explicitly declaring the originating exception * /exc = NewException(); exc.__context__ = None; raise exc/ Very verbose way of the previous method * /raise NewException.no_context(...)/ Make context suppression a class method. All of the above options will require changes to the core. Proposal I proprose going with the second option: raise NewException from None It has the advantage of using the existing pattern of explicitly setting the cause: raise KeyError() from NameError() but because the cause is /None/ the previous context is not displayed by the default exception printing routines. Implementation Discussion = Currently, /None/ is the default for both /__context__/ and /__cause__/. In order to support /raise ... from None/ (which would set /__cause__/ to /None/) we need a different default value for /__cause__/. Several ideas were put forth on how to implement this at the language level: * Overwrite the previous exception information (side-stepping the issue and leaving /__cause__/ at /None/). Rejected as this can seriously hinder debugging due to `poor error messages`_. * Use one of the boolean values in /__cause__/: /False/ would be the default value, and would be replaced when /from .../ was used with the explicity chained exception or /None/. Rejected as this encourages the use of two different objects types for /__cause__/ with one of them (boolean) not allowed to have the full range of possible values (/True/ would never be used). * Create a special exception class, /__NoException__/. Rejected as possibly confusing, possibly being mistakenly raised by users, and not being a truly unique value as /None/, /True/, and /False/ are. * Use /Ellipsis/ as the default value (the /.../ singleton). Accepted. There are no other possible values; it cannot be raised as it is not an acception; it has the connotation of 'fill in the rest...' as in /__cause__/ is not set, look in /__context__/ for it. Language Details To support /from None/, /__context__/ will stay as it is, but /__cause__/ will start out as /Ellipsis/ and will change to /None/ when the /raise ... from None/ method is used. == == == form__context__ __cause__ == == == raise /None/ /Ellipsis/ reraise previous exception /Ellipsis/ reraise fromprevious exception /None/ | /None/ | /ChainedException/ explicitly chained exception == == == The default exception printing routine will then: * If /__cause__/ is /Ellipsis/ the /__context__/ (if any) will be printed. * If /__cause__/ is /None/ the /__context__/ will not be printed. * if /__cause__/ is anything else, /__cause__/ will be printed. Patches === There is a patch for CPython implementing this attached to `Issue 6210`_. References == Discussion and refinements in this `thread on python-dev`_. .. _poor error messages: http://bugs.python.org/msg152294 .. _issue 6210: http://bugs.python.org/issue6210 .. _Thread on python-dev: http://mail.python.org/pipermail/python-dev/2012-January/115838.html Copyright = This document has been placed in the public
Re: [Python-Dev] PEP 409 update [was: PEP 409 - final?]
On 2/2/2012 2:10 PM, Ethan Furman wrote: * Use /Ellipsis/ as the default value (the /.../ singleton). Accepted. There are no other possible values; it cannot be raised as it is not an acception; it has the connotation of 'fill in the rest...' as in /__cause__/ is not set, look in /__context__/ for it. exception rather that acception (whatever that means) ___ 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] PEP: New timestamp formats
On 2/2/2012 6:28 AM, Antoine Pitrou wrote: On Thu, 2 Feb 2012 15:09:41 +0100 Victor Stinnervictor.stin...@haypocalc.com wrote: Why int? That doesn't seem to bring anything. It helps to deprecate/replace os.stat_float_times(), which may be used for backward compatibility (with Python 2.2 ? :-)). I must admit I don't understand the stat_float_times documentation: “For compatibility with older Python versions, accessing stat_result as a tuple always returns integers. Python now returns float values by default. Applications which do not work correctly with floating point time stamps can use this function to restore the old behaviour.” These two paragraphs seem to contradict themselves. That said, I don't understand why we couldn't simply deprecate stat_float_times() right now. Having an option for integer timestamps is pointless, you can just call int() on the result if you want. Regards Antoine. Sorry to bring this up, but the PEP should probably consider another option: Introducing a precedent following os.stat_decimal_times(). Like os.stat_float_times, it would decide the return types of timestamps from os.stat. Or something along that line. Having it affect the results of time.time would be weird, though. And the whole design of os.stat_float_times smells of something being designed wrong in the first place, to need such an API to retain backward compatibility. But I'm not sure it is, even yet, designed for such flexibility. ___ 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] PEP 409 update [was: PEP 409 - final?]
Great, PEP 409 is accepted with Ellipsis instead of False! On Thu, Feb 2, 2012 at 2:40 PM, Glenn Linderman v+pyt...@g.nevcal.com wrote: On 2/2/2012 2:10 PM, Ethan Furman wrote: * Use /Ellipsis/ as the default value (the /.../ singleton). Accepted. There are no other possible values; it cannot be raised as it is not an acception; it has the connotation of 'fill in the rest...' as in /__cause__/ is not set, look in /__context__/ for it. exception rather that acception (whatever that means) ___ 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/guido%40python.org -- --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] PEP 409 update [was: PEP 409 - final?]
In my opinion using Ellipsis is just wrong. It is completely non-obvious not only to a beginner, but even to an experienced python developer. Writing 'raise Something() from None' looks less suspicious, but still strange. Isn't 'raise Exception().no_context()' or 'raise Exception().no_cause()' more obvious and easy to implement? More readable, less complex and ambiguous. On 2012-02-02, at 5:10 PM, Ethan Furman wrote: PEP: 409 Title: Suppressing exception context Version: $Revision$ Last-Modified: $Date$ Author: Ethan Furman et...@stoneleaf.us Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 26-Jan-2012 Post-History: 30-Aug-2002, 01-Feb-2012, 03-Feb-2012 Abstract One of the open issues from PEP 3134 is suppressing context: currently there is no way to do it. This PEP proposes one. Rationale = There are two basic ways to generate exceptions: 1) Python does it (buggy code, missing resources, ending loops, etc.) 2) manually (with a raise statement) When writing libraries, or even just custom classes, it can become necessary to raise exceptions; moreover it can be useful, even necessary, to change from one exception to another. To take an example from my dbf module: try: value = int(value) except Exception: raise DbfError(...) Whatever the original exception was (/ValueError/, /TypeError/, or something else) is irrelevant. The exception from this point on is a /DbfError/, and the original exception is of no value. However, if this exception is printed, we would currently see both. Alternatives Several possibilities have been put forth: * /raise as NewException()/ Reuses the /as/ keyword; can be confusing since we are not really reraising the originating exception * /raise NewException() from None/ Follows existing syntax of explicitly declaring the originating exception * /exc = NewException(); exc.__context__ = None; raise exc/ Very verbose way of the previous method * /raise NewException.no_context(...)/ Make context suppression a class method. All of the above options will require changes to the core. Proposal I proprose going with the second option: raise NewException from None It has the advantage of using the existing pattern of explicitly setting the cause: raise KeyError() from NameError() but because the cause is /None/ the previous context is not displayed by the default exception printing routines. Implementation Discussion = Currently, /None/ is the default for both /__context__/ and /__cause__/. In order to support /raise ... from None/ (which would set /__cause__/ to /None/) we need a different default value for /__cause__/. Several ideas were put forth on how to implement this at the language level: * Overwrite the previous exception information (side-stepping the issue and leaving /__cause__/ at /None/). Rejected as this can seriously hinder debugging due to `poor error messages`_. * Use one of the boolean values in /__cause__/: /False/ would be the default value, and would be replaced when /from .../ was used with the explicity chained exception or /None/. Rejected as this encourages the use of two different objects types for /__cause__/ with one of them (boolean) not allowed to have the full range of possible values (/True/ would never be used). * Create a special exception class, /__NoException__/. Rejected as possibly confusing, possibly being mistakenly raised by users, and not being a truly unique value as /None/, /True/, and /False/ are. * Use /Ellipsis/ as the default value (the /.../ singleton). Accepted. There are no other possible values; it cannot be raised as it is not an acception; it has the connotation of 'fill in the rest...' as in /__cause__/ is not set, look in /__context__/ for it. Language Details To support /from None/, /__context__/ will stay as it is, but /__cause__/ will start out as /Ellipsis/ and will change to /None/ when the /raise ... from None/ method is used. == == == form__context__ __cause__ == == == raise /None/ /Ellipsis/ reraise previous exception /Ellipsis/ reraise fromprevious exception /None/ | /None/ | /ChainedException/ explicitly chained exception == == == The default exception printing routine will then: * If /__cause__/ is /Ellipsis/ the /__context__/ (if any) will be printed. * If /__cause__/ is /None/ the /__context__/
[Python-Dev] open issues on accepted PEPs
I was looking at the other Open Issues on PEP 3134, think I might try to resolve them as well, and discovered via testing that they have already been taken care of. Is there an established way to get information like that? I realize that PEPs are partly historical documents, but it would it make sense to add a note after an Open Issue (or any other section) that was refined, resolved, or whatever in a later PEP or bug or patch or ...* ~Ethan~ *Yes, I am volunteering to tackle that project. ___ 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] PEP: New timestamp formats
On Fri, Feb 3, 2012 at 8:37 AM, Glenn Linderman v+pyt...@g.nevcal.com wrote: Sorry to bring this up, but the PEP should probably consider another option: Introducing a precedent following os.stat_decimal_times(). Like os.stat_float_times, it would decide the return types of timestamps from os.stat. Or something along that line. Having it affect the results of time.time would be weird, though. And the whole design of os.stat_float_times smells of something being designed wrong in the first place, to need such an API to retain backward compatibility. But I'm not sure it is, even yet, designed for such flexibility. We could get away with a global switch for the int-float transition because ints and floats interoperate pretty well. The same is not true for binary floats and decimal.Decimal. 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] PEP 409 update [was: PEP 409 - final?]
On Fri, Feb 3, 2012 at 9:32 AM, Yury Selivanov yselivanov...@gmail.com wrote: In my opinion using Ellipsis is just wrong. It is completely non-obvious not only to a beginner, but even to an experienced python developer. Writing 'raise Something() from None' looks less suspicious, but still strange. Beginners will never even see it (unless they're printing out __cause__ explicitly for some unknown reason). Experienced devs can go read language reference or PEP 409 for the rationale (that's one of the reasons we have a PEP process). 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] open issues on accepted PEPs
On Fri, Feb 3, 2012 at 9:16 AM, Ethan Furman et...@stoneleaf.us wrote: I was looking at the other Open Issues on PEP 3134, think I might try to resolve them as well, and discovered via testing that they have already been taken care of. Is there an established way to get information like that? I realize that PEPs are partly historical documents, but it would it make sense to add a note after an Open Issue (or any other section) that was refined, resolved, or whatever in a later PEP or bug or patch or ...* If that kind of thing comes up, updating the PEP directly is definitely a reasonable way to clarify things. If people want to see the *exact* state of the PEP when it was accepted, they're all under version control. What we actually do depends on the specifics of the PEP, though (and whether or not anyone feels motivated to clarify things!). 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] PEP 409 update [was: PEP 409 - final?]
Glenn Linderman wrote: On 2/2/2012 2:10 PM, Ethan Furman wrote: * Use /Ellipsis/ as the default value (the /.../ singleton). Accepted. There are no other possible values; it cannot be raised as it is not an acception; it has the connotation of 'fill in the rest...' as in /__cause__/ is not set, look in /__context__/ for it. exception rather that acception (whatever that means) Argh. Kinda sounds like a royal ball... Thanks. ~Ethan~ ___ 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] PEP 409 update [was: PEP 409 - final?]
On Thu, Feb 2, 2012 at 3:41 PM, Nick Coghlan ncogh...@gmail.com wrote: On Fri, Feb 3, 2012 at 9:32 AM, Yury Selivanov yselivanov...@gmail.com wrote: In my opinion using Ellipsis is just wrong. It is completely non-obvious not only to a beginner, but even to an experienced python developer. Writing 'raise Something() from None' looks less suspicious, but still strange. Beginners will never even see it (unless they're printing out __cause__ explicitly for some unknown reason). Experienced devs can go read language reference or PEP 409 for the rationale (that's one of the reasons we have a PEP process). I somehow have a feeling that Yury misread the PEP (or maybe my +1) as saying that the syntax for suppressing the context would be raise exception from Ellipsis. That's not the case, it's from None. -- --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] PEP: New timestamp formats
I updated and completed my PEP and published the last draft. It will be available at: http://www.python.org/dev/peps/pep-0410/ ( or read the source: http://hg.python.org/peps/file/tip/pep-0410.txt ) I tried to list all alternatives. Victor ___ 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] PEP 409 update [was: PEP 409 - final?]
On Fri, Feb 3, 2012 at 10:04 AM, Guido van Rossum gu...@python.org wrote: On Thu, Feb 2, 2012 at 3:41 PM, Nick Coghlan ncogh...@gmail.com wrote: On Fri, Feb 3, 2012 at 9:32 AM, Yury Selivanov yselivanov...@gmail.com wrote: In my opinion using Ellipsis is just wrong. It is completely non-obvious not only to a beginner, but even to an experienced python developer. Writing 'raise Something() from None' looks less suspicious, but still strange. Beginners will never even see it (unless they're printing out __cause__ explicitly for some unknown reason). Experienced devs can go read language reference or PEP 409 for the rationale (that's one of the reasons we have a PEP process). I somehow have a feeling that Yury misread the PEP (or maybe my +1) as saying that the syntax for suppressing the context would be raise exception from Ellipsis. That's not the case, it's from None. Oh right, that objection makes more sense. FWIW, I expect the implementation will *allow* raise exc from Ellipsis as an odd synonym for raise exc. I'd want to allow exc.__cause__ = Ellipsis to reset an exception with a previously set __cause__ back to the default state, at which point the synonym follows from the semantics of raise X from Y as syntactic sugar for _exc = X; _exc.__cause__ = Y; raise _exc 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] open issues on accepted PEPs
Nick Coghlan wrote: On Fri, Feb 3, 2012 at 9:16 AM, Ethan Furman et...@stoneleaf.us wrote: I was looking at the other Open Issues on PEP 3134, think I might try to resolve them as well, and discovered via testing that they have already been taken care of. Is there an established way to get information like that? I realize that PEPs are partly historical documents, but it would it make sense to add a note after an Open Issue (or any other section) that was refined, resolved, or whatever in a later PEP or bug or patch or ...* If that kind of thing comes up, updating the PEP directly is definitely a reasonable way to clarify things. If people want to see the *exact* state of the PEP when it was accepted, they're all under version control. What we actually do depends on the specifics of the PEP, though (and whether or not anyone feels motivated to clarify things!). Okay. I would like to put links to the updates to the Open Issues in PEP3134 -- is there an easier way to find those besides typing in 'exception' in the bug tracker? I would like to complete that task in /this/ lifetime. ;) ~Ethan~ ___ 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] PEP 409 update [was: PEP 409 - final?]
Guido van Rossum wrote: Great, PEP 409 is accepted with Ellipsis instead of False! Awesome. :) ~Ethan~ ___ 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] PEP: New timestamp formats
On Fri, Feb 3, 2012 at 10:21 AM, Victor Stinner victor.stin...@haypocalc.com wrote: I updated and completed my PEP and published the last draft. It will be available at: http://www.python.org/dev/peps/pep-0410/ ( or read the source: http://hg.python.org/peps/file/tip/pep-0410.txt ) I tried to list all alternatives. Looks pretty good to me, just a few comments in regards to the descriptions of the alternatives (I'm not advocating for any the rejected options any more, since I'm happy with the current proposal, but the PEP should be clear on our reasons for rejecting them): decimal.Decimal - using this by default *was* considered, but rejected due to the bootstrapping problem (decimals are not builtin) and the compatibility problem (decimals do not play nicely with binary floats) - the chosen API also relates to the bootstrapping problem - since decimal.Decimal is passed in to the API directly, the builtin modules don't need to perform their own implicit import to get access to the type datetime.datetime - as noted earlier in the thread, total_seconds() actually gives you a decent timestamp value and always returning UTC avoids timezone issues - real problem with the idea is that not all timestamps can be easily made absolute (e.g. some APIs may return time since system started or time since process started) - the complexity argument used against timedelta also applies tuple of integers - option B doesn't force loss of precision, it's just awkward because you have to do a complicated calculation to express the full precision fraction in base 10 - option C only requires that the denominator be expressible as a power of *some* base. That's the case for all interfaces we're aware of (either a power of 2 or a power of 10). protocol - should explicitly note that the tuple of integers format discussion is relevant to any such protocol design - explicitly note that this was rejected as being excessive given the requirements, but that the specific syntax proposed allows this to be introduced later if compelling use cases are discovered boolean argument - should note explicitly that this was rejected because we don't generally like having argument *values* change return *types* (in cases like 3.3's IOError, where values can determine the specific *subclass* created, there's still a common parent type). -- 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] PEP: New timestamp formats
On 2/2/2012 3:38 PM, Nick Coghlan wrote: On Fri, Feb 3, 2012 at 8:37 AM, Glenn Lindermanv+pyt...@g.nevcal.com wrote: Sorry to bring this up, but the PEP should probably consider another option: Introducing a precedent following os.stat_decimal_times(). Like os.stat_float_times, it would decide the return types of timestamps from os.stat. Or something along that line. Having it affect the results of time.time would be weird, though. And the whole design of os.stat_float_times smells of something being designed wrong in the first place, to need such an API to retain backward compatibility. But I'm not sure it is, even yet, designed for such flexibility. We could get away with a global switch for the int-float transition because ints and floats interoperate pretty well. The same is not true for binary floats and decimal.Decimal. I agree about the interoperability of the various types, but don't see why that doesn't mean a global switch couldn't work, although I'm not fond of global switches. Library code that calls os.stat would have to be ready to handle either return value, but could predetermine it by checking the switch state. Icky. But possible. In any case, mentioning it in the PEP, along with why it is a bad idea, is probably a good idea. ___ 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] PEP: New timestamp formats
On Thu, 2 Feb 2012 16:25:25 +0100 Victor Stinner victor.stin...@haypocalc.com wrote: That said, I don't understand why we couldn't simply deprecate stat_float_times() right now. Having an option for integer timestamps is pointless, you can just call int() on the result if you want. So which API do you propose for time.time() to get a Decimal object? time.time(timestamp=decimal.Decimal) time.time(decimal=True) or time.time(hires=True) time.time(type=decimal.Decimal) sounds fine. If you want a boolean argument, either `decimal=True` or `exact=True`. Regards Antoine. ___ 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] PEP 409 update [was: PEP 409 - final?]
On Thu, Feb 2, 2012 at 4:34 PM, Nick Coghlan ncogh...@gmail.com wrote: On Fri, Feb 3, 2012 at 10:04 AM, Guido van Rossum gu...@python.org wrote: On Thu, Feb 2, 2012 at 3:41 PM, Nick Coghlan ncogh...@gmail.com wrote: On Fri, Feb 3, 2012 at 9:32 AM, Yury Selivanov yselivanov...@gmail.com wrote: In my opinion using Ellipsis is just wrong. It is completely non-obvious not only to a beginner, but even to an experienced python developer. Writing 'raise Something() from None' looks less suspicious, but still strange. Beginners will never even see it (unless they're printing out __cause__ explicitly for some unknown reason). Experienced devs can go read language reference or PEP 409 for the rationale (that's one of the reasons we have a PEP process). I somehow have a feeling that Yury misread the PEP (or maybe my +1) as saying that the syntax for suppressing the context would be raise exception from Ellipsis. That's not the case, it's from None. Oh right, that objection makes more sense. FWIW, I expect the implementation will *allow* raise exc from Ellipsis as an odd synonym for raise exc. I'd want to allow exc.__cause__ = Ellipsis to reset an exception with a previously set __cause__ back to the default state, at which point the synonym follows from the semantics of raise X from Y as syntactic sugar for _exc = X; _exc.__cause__ = Y; raise _exc Sure. But those are all rather obscure cases. Ellipsis reads no less or more obscure than False when written explicitly. But that doesn't bother me. -- --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] PEP 409 update [was: PEP 409 - final?]
On Fri, Feb 3, 2012 at 12:42 PM, Ethan Furman et...@stoneleaf.us wrote: Nick Coghlan wrote: FWIW, I expect the implementation will *allow* raise exc from Ellipsis as an odd synonym for raise exc. Are we sure we want that? Raising from something not an exception seems counter-intuitive (None being the obvious exception). It isn't so much a matter of wanting it as Is it problematic enough to put any effort into preventing it? (since allowing it is a natural outcome of the obvious implementation). 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] PEP 409 update [was: PEP 409 - final?]
On Thu, Feb 2, 2012 at 6:49 PM, Nick Coghlan ncogh...@gmail.com wrote: On Fri, Feb 3, 2012 at 12:42 PM, Ethan Furman et...@stoneleaf.us wrote: Nick Coghlan wrote: FWIW, I expect the implementation will *allow* raise exc from Ellipsis as an odd synonym for raise exc. Are we sure we want that? Raising from something not an exception seems counter-intuitive (None being the obvious exception). It isn't so much a matter of wanting it as Is it problematic enough to put any effort into preventing it? (since allowing it is a natural outcome of the obvious implementation). I would say yes we want that. It would be strange if you couldn't reset a variable explicitly to its default value. I don't expect people to do this often. But somebody might want to do a deep copy of an exception (with some systematic change), or there might be other reasons. I'm sure a few Python zen items apply here. :-) -- --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] PEP 409 update [was: PEP 409 - final?]
Guido van Rossum wrote: On Thu, Feb 2, 2012 at 6:49 PM, Nick Coghlan ncogh...@gmail.com wrote: On Fri, Feb 3, 2012 at 12:42 PM, Ethan Furman et...@stoneleaf.us wrote: Nick Coghlan wrote: FWIW, I expect the implementation will *allow* raise exc from Ellipsis as an odd synonym for raise exc. Are we sure we want that? Raising from something not an exception seems counter-intuitive (None being the obvious exception). It isn't so much a matter of wanting it as Is it problematic enough to put any effort into preventing it? (since allowing it is a natural outcome of the obvious implementation). I would say yes we want that. It would be strange if you couldn't reset a variable explicitly to its default value. I don't expect people to do this often. But somebody might want to do a deep copy of an exception (with some systematic change), or there might be other reasons. I'm sure a few Python zen items apply here. :-) Okey-doke, I'll get it going. ~Ethan~ ___ 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] PEP 409 update [was: PEP 409 - final?]
On 3 February 2012 13:54, Guido van Rossum gu...@python.org wrote: On Thu, Feb 2, 2012 at 6:49 PM, Nick Coghlan ncogh...@gmail.com wrote: On Fri, Feb 3, 2012 at 12:42 PM, Ethan Furman et...@stoneleaf.us wrote: Nick Coghlan wrote: FWIW, I expect the implementation will *allow* raise exc from Ellipsis as an odd synonym for raise exc. Are we sure we want that? Raising from something not an exception seems counter-intuitive (None being the obvious exception). It isn't so much a matter of wanting it as Is it problematic enough to put any effort into preventing it? (since allowing it is a natural outcome of the obvious implementation). I would say yes we want that. It would be strange if you couldn't reset a variable explicitly to its default value. In that case, would the best syntax be: raise Exception() from Ellipsis or: raise Exception() from ... ? I kinda like the second - it feels more self-descriptive to me than from Ellipsis - but there's the counter-argument that it could look like noise, and I think would require a grammar change to allow it there. Tim Delaney ___ 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] PEP 409 update [was: PEP 409 - final?]
Nick Coghlan wrote: FWIW, I expect the implementation will *allow* raise exc from Ellipsis as an odd synonym for raise exc. Are we sure we want that? Raising from something not an exception seems counter-intuitive (None being the obvious exception). I'd want to allow exc.__cause__ = Ellipsis to reset an exception with a previously set __cause__ back to the default state, Already done. :) at which point the synonym follows from the semantics of raise X from Y as syntactic sugar for _exc = X; _exc.__cause__ = Y; raise _exc I can see where it would make some sense that way, but it still seems odd. ~Ethan~ ___ 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] PEP 409 update [was: PEP 409 - final?]
On Fri, Feb 3, 2012 at 1:34 PM, Tim Delaney timothy.c.dela...@gmail.com wrote: ? I kinda like the second - it feels more self-descriptive to me than from Ellipsis - but there's the counter-argument that it could look like noise, and I think would require a grammar change to allow it there. Both will be allowed - in 3.x, '...' is just an ordinary expression that means exactly the same thing as the builtin Ellipsis: Ellipsis Ellipsis ... Ellipsis Sane code almost certainly won't include *either* form, though. If you're reraising an exception, you should generally be leaving __cause__ and __context__ alone, and if you're raising a *new* exception, then __cause__ will already be Ellipsis by default - you only need to use raise X from Y to set it to something *else*. As I noted earlier, supporting Ellipsis in the raise X from Y syntax shouldn't require a code change in Ethan's implementation, just a few additional tests to ensure it works as expected. 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] PEP 409 update [was: PEP 409 - final?]
Tim Delaney wrote: In that case, would the best syntax be: raise Exception() from Ellipsis or: raise Exception() from ... ? I kinda like the second - it feels more self-descriptive to me than from Ellipsis - but there's the counter-argument that it could look like noise, and I think would require a grammar change to allow it there. raise Exception() from ... is... well, I am now gleeful -- especially since I went to my fresh copy of Python 3.3.0a0 and did this: -- ... Ellipsis -- raise ValueError from ... Traceback (most recent call last): File stdin, line 1, in module ValueError Have I said lately how much I *love* Python? ~Ethan~ ___ 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] PEP 409 update [was: PEP 409 - final?]
On 3 February 2012 15:02, Nick Coghlan ncogh...@gmail.com wrote: Both will be allowed - in 3.x, '...' is just an ordinary expression that means exactly the same thing as the builtin Ellipsis: Ellipsis Ellipsis ... Ellipsis I'd totally forgotten that was the case in 3.x ... it's still not exactly common to use Ellipsis/... directly except in extended slicing. Sane code almost certainly won't include *either* form, though. If you're reraising an exception, you should generally be leaving __cause__ and __context__ alone, and if you're raising a *new* exception, then __cause__ will already be Ellipsis by default - you only need to use raise X from Y to set it to something *else*. Absolutely - I can't think of a reason to want to reraise an existing exception while supressing any existing __cause__ in favour of __context__. But I'm sure someone can. Tim Delaney ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3 optimizations, continued, continued again...
I really don't think that is a problem. The core contributors can deal well with complexity in my experience. :-) No no, I wasn't trying to insinuate anything like that at all. No, I just figured that having the code generator being able to generate 4 optimizations where only one is supported is a bad idea for several reasons, such as maintainability, etc. Anyways, I've just completed the integration of the code generator and put the corresponding patch on my page (http://www.ics.uci.edu/~sbruntha/pydev.html) for downloading. The license thing is still missing, I'll do that tomorrow or sometime next week. Regards, --stefan ___ 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
