Re: [Python-Dev] Python 2.x and 3.x use survey, 2014 edition
On Mon, 15 Dec 2014 19:08:17 -0800
Mark Roberts wiz...@gmail.com wrote:
So, I'm the guy that used the hate word in relation to writing 2/3
compliant code. And really, as a library maintainer/writer I do hate
writing 2/3 compatible code. Having 4 future imports in every file and
being forced to use a compatibility shim to do something as simple as
iterating across a dictionary is somewhere between sad and infuriating -
and that's just the beginning of the madness.
Iterating accross a dictionary doesn't need compatibility shims. It's
dead simple in all Python versions:
$ python2
Python 2.7.8 (default, Oct 20 2014, 15:05:19)
[GCC 4.9.1] on linux2
Type help, copyright, credits or license for more information.
d = {'a': 1}
for k in d: print(k)
...
a
$ python3
Python 3.4.2 (default, Oct 8 2014, 13:08:17)
[GCC 4.9.1] on linux
Type help, copyright, credits or license for more information.
d = {'a': 1}
for k in d: print(k)
...
a
Besides, using iteritems() and friends is generally a premature
optimization, unless you know you'll have very large containers.
Creating a list is cheap.
From there we get into
identifier related problems with their own compatibility shims - like
str(), unicode(), bytes(), int(), and long(). Writing 2/3 compatible Python
feels more like torture than fun.
It depends what kind of purpose your code is written for, or how you
write it. Unless you have a lot of network-facing code, writing 2/3
compatible code should actually be quite pedestrian.
Regards
Antoine.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.x and 3.x use survey, 2014 edition
On Sun, Dec 14, 2014 at 1:14 AM, Nick Coghlan ncogh...@gmail.com wrote: [...] Barry, Petr, any of the other folks working on distro level C extension ports, perhaps one of you would be willing to consider an update to the C extension porting guide to be more in line with Brett's latest version of the Python level porting guide? I can make it a 20%-time project starting in January, if no-one beats me to it. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] datetime nanosecond support (ctd?)
Agreed with Antoine, strftime/strptime are somewhat different concerns.
Doesn't mean thay cannot be fixed at the same time but it's a bit a
separate.
I'm not sure this thread / discussion has reached critical mass yet,
meanwhile I was looking at what was involved and came up with this
half-baked patch - by no way meant to be complete or correct, but rather
get a feel to it.
I can't help thinking this is much more involved than I first expected,
and what I try to achieve should be reasonably simple.
Stepping back a little, I wonder if the datetime module is really the
right location, that has constructor(year, month, day, ..., second,
microsecond) - with 0ms99, no millis. adding 0ns999 would seem
quite ugly, in fact nothing looks quite right.
datetime seems to be dealing with 'calendar time' stuff - and to some
extent, maybe, shouldn't concern itself so much with fraction of seconds.
I'm pondering now if the 'time' module that seems to be dealing with
'computer clock time' wouldn't be a better target to introduce
struct_timespec and the like.
I'd be curious to hear back from this list, if this deserves more
investigation or what might be a better way to go.
Regards,
Matthieu
On 12/11/2014 11:46 AM, Antoine Pitrou wrote:
On Thu, 11 Dec 2014 13:43:05 -0600
Skip Montanaro skip.montan...@gmail.com wrote:
On Thu, Dec 11, 2014 at 1:23 PM, Antoine Pitrou solip...@pitrou.net wrote:
I think strftime / strptime support is a low-priority concern on this
topic, and can probably be discussed independently of the core
nanosecond support.
Might be low-priority, but with %f support as a template, supporting
something to specify nanoseconds should be pretty trivial. The hardest
question will be to convince ourselves that we aren't choosing a
format code which some other strftime/strptime implementation is
already using.
In addition, ISTR that one of the use cases was analysis of datetime
data generated by other applications which has nanosecond resolution.
One of the use cases is to deal with OS-generated timestamps without
losing information. As long as you don't need to represent or parse
those timestamps, strptime / strftime don't come into the picture.
Regards
Antoine.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/mdcb808%40gmail.com
--
Matthieu BecGMTO Corp
cell : +1 626 425 7923 251 S Lake Ave, Suite 300
phone: +1 626 204 0527 Pasadena, CA 91101
diff -r 5754f069b123 Include/datetime.h
--- a/Include/datetime.h Sat Nov 22 12:54:57 2014 -0800
+++ b/Include/datetime.h Tue Dec 16 09:04:35 2014 -0800
@@ -18,18 +18,34 @@
* 5 minute 1 byte, 0-59
* 6 second 1 byte, 0-59
* 7 usecond 3 bytes, 0-99
- * 10
+ * 10 nsecond 2 bytes, 0-999
+ * 12
*/
/* # of bytes for year, month, and day. */
#define _PyDateTime_DATE_DATASIZE 4
-/* # of bytes for hour, minute, second, and usecond. */
-#define _PyDateTime_TIME_DATASIZE 6
+/* # of bytes for hour, minute, second, usecond and nsecond. */
+#define _PyDateTime_TIME_DATASIZE 8
+#define _PyDateTime_TIME_DATASIZE_V0 6 /* older version used for backward compatibility access */
-/* # of bytes for year, month, day, hour, minute, second, and usecond. */
-#define _PyDateTime_DATETIME_DATASIZE 10
+/* # of bytes for year, month, day, hour, minute, second, usecond and nsecond. */
+#define _PyDateTime_DATETIME_DATASIZE 12
+#define _PyDateTime_DATETIME_DATASIZE_V0 10 /* older version used for backward compatibility access */
+/* max usecond is hex(1e6) = 0x0f4240, hence the 4 upper bits that are not used to encode the
+ * number of milliseconds can be used for pickle versioning.
+ */
+#define _PyDateTime_USECOND_MSB_VALUE_MASK 0x0f
+#define _PyDateTime_USECOND_MSB_PICKLEVERSION_MASK 0xf0
+/* up to 15 pickle versions are available
+ * version 0 is vanilla
+ * version 1 adds nanosecond (this version)
+ * version 2..15 are available for future upgrades
+ */
+#define _PyDateTime_PICKLE_V0_VANILLA 0
+#define _PyDateTime_PICKLE_V1_NANOSECOND 1
+#define _PyDateTime_PICKLE_CURRENT_VERSION _PyDateTime_PICKLE_V1_NANOSECOND
typedef struct
{
@@ -38,6 +54,7 @@
int days; /* -MAX_DELTA_DAYS = days = MAX_DELTA_DAYS */
int seconds;/* 0 = seconds 24*3600 is invariant */
int microseconds; /* 0 = microseconds 100 is invariant */
+int nanoseconds;/* 0 = nanoseconds 1000 is invariant */
} PyDateTime_Delta;
typedef struct
@@ -122,18 +139,30 @@
#define PyDateTime_DATE_GET_MINUTE(o) (((PyDateTime_DateTime*)o)-data[5])
#define PyDateTime_DATE_GET_SECOND(o) (((PyDateTime_DateTime*)o)-data[6])
#define PyDateTime_DATE_GET_MICROSECOND(o) \
-PyDateTime_DateTime*)o)-data[7] 16) | \
+
Re: [Python-Dev] Python 2.x and 3.x use survey, 2014 edition
On Tue, Dec 16, 2014 at 2:45 AM, Antoine Pitrou solip...@pitrou.net wrote:
Iterating accross a dictionary doesn't need compatibility shims. It's
dead simple in all Python versions:
$ python2
Python 2.7.8 (default, Oct 20 2014, 15:05:19)
[GCC 4.9.1] on linux2
Type help, copyright, credits or license for more information.
d = {'a': 1}
for k in d: print(k)
...
a
$ python3
Python 3.4.2 (default, Oct 8 2014, 13:08:17)
[GCC 4.9.1] on linux
Type help, copyright, credits or license for more information.
d = {'a': 1}
for k in d: print(k)
...
a
Besides, using iteritems() and friends is generally a premature
optimization, unless you know you'll have very large containers.
Creating a list is cheap.
It seems to me that every time I hear this, the author is basically
admitting that Python is a toy language not meant for serious computing
(where serious is defined in extremely modest terms). The advice is also
very contradictory to literally every talk on performant Python that I've
seen at PyCon or PyData or ... well, anywhere. And really, doesn't it
strike you as incredibly presumptuous to call the *DEFAULT BEHAVIOR* of
Python 3 a premature optimization? Isn't the whole reason that the
default behavior switch was made is because creating lists willy nilly all
over the place really *ISN'T* cheap? This isn't the first time someone has
tried to run this line past me, but it's the first time I've been fed up
enough with the topic to call it complete BS on the spot. Please help me
stop the community at large from saying this, because it really isn't true
at all.
-Mark
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.x and 3.x use survey, 2014 edition
Mark, your tone is no longer constructive and is hurting your case in
arguing for anything. Please take it down a notch.
On Tue Dec 16 2014 at 1:48:59 PM Mark Roberts wiz...@gmail.com wrote:
On Tue, Dec 16, 2014 at 2:45 AM, Antoine Pitrou solip...@pitrou.net
wrote:
Iterating accross a dictionary doesn't need compatibility shims. It's
dead simple in all Python versions:
$ python2
Python 2.7.8 (default, Oct 20 2014, 15:05:19)
[GCC 4.9.1] on linux2
Type help, copyright, credits or license for more information.
d = {'a': 1}
for k in d: print(k)
...
a
$ python3
Python 3.4.2 (default, Oct 8 2014, 13:08:17)
[GCC 4.9.1] on linux
Type help, copyright, credits or license for more information.
d = {'a': 1}
for k in d: print(k)
...
a
Besides, using iteritems() and friends is generally a premature
optimization, unless you know you'll have very large containers.
Creating a list is cheap.
It seems to me that every time I hear this, the author is basically
admitting that Python is a toy language not meant for serious computing
(where serious is defined in extremely modest terms). The advice is also
very contradictory to literally every talk on performant Python that I've
seen at PyCon or PyData or ... well, anywhere. And really, doesn't it
strike you as incredibly presumptuous to call the *DEFAULT BEHAVIOR* of
Python 3 a premature optimization? Isn't the whole reason that the
default behavior switch was made is because creating lists willy nilly all
over the place really *ISN'T* cheap? This isn't the first time someone has
tried to run this line past me, but it's the first time I've been fed up
enough with the topic to call it complete BS on the spot. Please help me
stop the community at large from saying this, because it really isn't true
at all.
-Mark
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: https://mail.python.org/mailman/options/python-dev/
brett%40python.org
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.x and 3.x use survey, 2014 edition
Perhaps you are correct, and I will attempt to remain more constructive on
the topic (despite it being an *incredibly* frustrating experience).
However, my point remains: this is a patently false thing that is being
parroted throughout the Python community, and it's outright insulting to be
told my complaints about writing 2/3 compatible code are invalid on the
basis of premature optimization.
-Mark
On Tue, Dec 16, 2014 at 10:57 AM, Brett Cannon br...@python.org wrote:
Mark, your tone is no longer constructive and is hurting your case in
arguing for anything. Please take it down a notch.
On Tue Dec 16 2014 at 1:48:59 PM Mark Roberts wiz...@gmail.com wrote:
On Tue, Dec 16, 2014 at 2:45 AM, Antoine Pitrou solip...@pitrou.net
wrote:
Iterating accross a dictionary doesn't need compatibility shims. It's
dead simple in all Python versions:
$ python2
Python 2.7.8 (default, Oct 20 2014, 15:05:19)
[GCC 4.9.1] on linux2
Type help, copyright, credits or license for more information.
d = {'a': 1}
for k in d: print(k)
...
a
$ python3
Python 3.4.2 (default, Oct 8 2014, 13:08:17)
[GCC 4.9.1] on linux
Type help, copyright, credits or license for more information.
d = {'a': 1}
for k in d: print(k)
...
a
Besides, using iteritems() and friends is generally a premature
optimization, unless you know you'll have very large containers.
Creating a list is cheap.
It seems to me that every time I hear this, the author is basically
admitting that Python is a toy language not meant for serious computing
(where serious is defined in extremely modest terms). The advice is also
very contradictory to literally every talk on performant Python that I've
seen at PyCon or PyData or ... well, anywhere. And really, doesn't it
strike you as incredibly presumptuous to call the *DEFAULT BEHAVIOR* of
Python 3 a premature optimization? Isn't the whole reason that the
default behavior switch was made is because creating lists willy nilly all
over the place really *ISN'T* cheap? This isn't the first time someone has
tried to run this line past me, but it's the first time I've been fed up
enough with the topic to call it complete BS on the spot. Please help me
stop the community at large from saying this, because it really isn't true
at all.
-Mark
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: https://mail.python.org/mailman/options/python-dev/
brett%40python.org
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] datetime nanosecond support (ctd?)
On Tue, Dec 16, 2014 at 11:10 AM, matthieu bec m...@gmto.org wrote: Agreed with Antoine, strftime/strptime are somewhat different concerns. Doesn't mean thay cannot be fixed at the same time but it's a bit a separate. Which reminds me... Somewhere else (maybe elsewhere in this thread? maybe on a bug tracker issue?) someone mentioned that Ruby uses %N for fractions of a second (and %L specifically for milliseconds). Here's the bit from the Ruby strftime doc: %L - Millisecond of the second (000..999) %N - Fractional seconds digits, default is 9 digits (nanosecond) %3N millisecond (3 digits) %6N microsecond (6 digits) %9N nanosecond (9 digits) %12N picosecond (12 digits) There's no obvious reason I can see to reinvent this particular wheel, at least the %N spoke. The only question might be whether to modify Python's existing %f format to accept a precision (defaulting to 6), or add %N in a manner similar (or identical) to Ruby's semantics. Skip ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.x and 3.x use survey, 2014 edition
On Tue, 16 Dec 2014 10:48:07 -0800, Mark Roberts wiz...@gmail.com wrote:
On Tue, Dec 16, 2014 at 2:45 AM, Antoine Pitrou solip...@pitrou.net wrote:
Iterating accross a dictionary doesn't need compatibility shims. It's
dead simple in all Python versions:
$ python2
Python 2.7.8 (default, Oct 20 2014, 15:05:19)
[GCC 4.9.1] on linux2
Type help, copyright, credits or license for more information.
d = {'a': 1}
for k in d: print(k)
...
a
$ python3
Python 3.4.2 (default, Oct 8 2014, 13:08:17)
[GCC 4.9.1] on linux
Type help, copyright, credits or license for more information.
d = {'a': 1}
for k in d: print(k)
...
a
Besides, using iteritems() and friends is generally a premature
optimization, unless you know you'll have very large containers.
Creating a list is cheap.
It seems to me that every time I hear this, the author is basically
admitting that Python is a toy language not meant for serious computing
(where serious is defined in extremely modest terms). The advice is also
very contradictory to literally every talk on performant Python that I've
seen at PyCon or PyData or ... well, anywhere. And really, doesn't it
strike you as incredibly presumptuous to call the *DEFAULT BEHAVIOR* of
Python 3 a premature optimization?
No. A premature optimization is one that is made before doing any
performance analysis, so language features are irrelevant to that
labeling. This doesn't mean you shouldn't use better idioms when they
are clear. But if you are complicating your code because of performance
concerns *without measuring it* you are doing premature optimization, by
definition[*].
Isn't the whole reason that the
default behavior switch was made is because creating lists willy nilly all
over the place really *ISN'T* cheap? This isn't the first time someone has
No. In Python3 we made the iterator protocol more central to the
language. Any performance benefit is actually a side effect of that
change. One that was considered, yes, but in the context of the
*language* as a whole and not any individual program's performance
profile. And this doesn't make things worse for real world programs as
far as we can measure is a more important criterion for this kind of
language change than lets do this because we've measured and it makes
things better.
--David
[*] And yes, *we all do this*. Sometimes doing it doesn't cost much.
Sometimes it does.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] datetime nanosecond support (ctd?)
I vote to copy Ruby's %N and leave %f alone. On Tue, Dec 16, 2014 at 11:08 AM, Skip Montanaro skip.montan...@gmail.com wrote: On Tue, Dec 16, 2014 at 11:10 AM, matthieu bec m...@gmto.org wrote: Agreed with Antoine, strftime/strptime are somewhat different concerns. Doesn't mean thay cannot be fixed at the same time but it's a bit a separate. Which reminds me... Somewhere else (maybe elsewhere in this thread? maybe on a bug tracker issue?) someone mentioned that Ruby uses %N for fractions of a second (and %L specifically for milliseconds). Here's the bit from the Ruby strftime doc: %L - Millisecond of the second (000..999) %N - Fractional seconds digits, default is 9 digits (nanosecond) %3N millisecond (3 digits) %6N microsecond (6 digits) %9N nanosecond (9 digits) %12N picosecond (12 digits) There's no obvious reason I can see to reinvent this particular wheel, at least the %N spoke. The only question might be whether to modify Python's existing %f format to accept a precision (defaulting to 6), or add %N in a manner similar (or identical) to Ruby's semantics. Skip ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/guido%40python.org -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] datetime nanosecond support (ctd?)
yes that was mentioned in this thread, %nN looks quite reasonable. still, I'd like to steer the conversation back to the other aspect - where should something like struct_timespec land in the first place, is datetime really the best to capture that? Most of the conversation has been revolving around strftime/strptime. That seems to validate Antoine's point in the first place. Let's see what people say but maybe this thread should end to restart as separate topics? Regards, Matthieu On 12/16/14 11:08 AM, Skip Montanaro wrote: On Tue, Dec 16, 2014 at 11:10 AM, matthieu bec m...@gmto.org mailto:m...@gmto.org wrote: Agreed with Antoine, strftime/strptime are somewhat different concerns. Doesn't mean thay cannot be fixed at the same time but it's a bit a separate. Which reminds me... Somewhere else (maybe elsewhere in this thread? maybe on a bug tracker issue?) someone mentioned that Ruby uses %N for fractions of a second (and %L specifically for milliseconds). Here's the bit from the Ruby strftime doc: %L - Millisecond of the second (000..999) %N - Fractional seconds digits, default is 9 digits (nanosecond) %3N millisecond (3 digits) %6N microsecond (6 digits) %9N nanosecond (9 digits) %12N picosecond (12 digits) There's no obvious reason I can see to reinvent this particular wheel, at least the %N spoke. The only question might be whether to modify Python's existing %f format to accept a precision (defaulting to 6), or add %N in a manner similar (or identical) to Ruby's semantics. Skip ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/mdcb808%40gmail.com -- Matthieu BecGMTO Corp cell : +1 626 425 7923 251 S Lake Ave, Suite 300 phone: +1 626 204 0527 Pasadena, CA 91101 ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] datetime nanosecond support (ctd?)
Aren't the wrappers for the kernel's time-related structs typically in the time module? That seems the place to start. Eventually we can support going between those structs and the datetype datatype (the latter may have to grow an option to specify nsec). On Tue, Dec 16, 2014 at 11:21 AM, Matthieu Bec m...@gmto.org wrote: yes that was mentioned in this thread, %nN looks quite reasonable. still, I'd like to steer the conversation back to the other aspect - where should something like struct_timespec land in the first place, is datetime really the best to capture that? Most of the conversation has been revolving around strftime/strptime. That seems to validate Antoine's point in the first place. Let's see what people say but maybe this thread should end to restart as separate topics? Regards, Matthieu On 12/16/14 11:08 AM, Skip Montanaro wrote: On Tue, Dec 16, 2014 at 11:10 AM, matthieu bec m...@gmto.org mailto:m...@gmto.org wrote: Agreed with Antoine, strftime/strptime are somewhat different concerns. Doesn't mean thay cannot be fixed at the same time but it's a bit a separate. Which reminds me... Somewhere else (maybe elsewhere in this thread? maybe on a bug tracker issue?) someone mentioned that Ruby uses %N for fractions of a second (and %L specifically for milliseconds). Here's the bit from the Ruby strftime doc: %L - Millisecond of the second (000..999) %N - Fractional seconds digits, default is 9 digits (nanosecond) %3N millisecond (3 digits) %6N microsecond (6 digits) %9N nanosecond (9 digits) %12N picosecond (12 digits) There's no obvious reason I can see to reinvent this particular wheel, at least the %N spoke. The only question might be whether to modify Python's existing %f format to accept a precision (defaulting to 6), or add %N in a manner similar (or identical) to Ruby's semantics. Skip ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/ mdcb808%40gmail.com -- Matthieu BecGMTO Corp cell : +1 626 425 7923 251 S Lake Ave, Suite 300 phone: +1 626 204 0527 Pasadena, CA 91101 ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/ guido%40python.org -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.x and 3.x use survey, 2014 edition
On Tue Dec 16 2014 at 2:05:28 PM Mark Roberts wiz...@gmail.com wrote:
Perhaps you are correct, and I will attempt to remain more constructive on
the topic (despite it being an *incredibly* frustrating experience).
However, my point remains: this is a patently false thing that is being
parroted throughout the Python community, and it's outright insulting to be
told my complaints about writing 2/3 compatible code are invalid on the
basis of premature optimization.
See, you're still using a very negative tone even after saying you would
try to scale it back. What Antoine said is not patently false and all he
said was that relying on iter*() methods on dicts is typically a premature
optimization for Python 2 code which is totally reasonable for him to say
and was done so in a calm tone. He didn't say you are prematurely
optimizing and you need to stop telling the community that because you're
wasting everyone's time in caring about performance! which how I would
expect you to state it if you were make the same claim based on how you
have been reacting.
For most use cases, you simply don't need a memory-efficient iterator. If
you have a large dict where memory issues from constructing a list comes
into play, then yes you should use iterkeys(), but otherwise the overhead
of temporarily constructing a list to hold all the keys is cheap since it's
just a list of pointers at the C level.
As for the changing of the default in Python 3, that's because we decided
to make iterators the default everywhere. And that was mostly for
consistency, not performance reasons. It was also for flexibility as you
can go from an iterator to a list by just wrapping the iterator in list(),
but you can't go the other way around. At no time did anyone go we really
need to change the default iterator for dicts to a memory-saving iterator
because people are wasting memory and having issues with memory pressure
all the time; it was always about consistency and using the best idiom
that had developed over the years.
So Antoine's point is entirely reasonable and valid and right.
-Brett
-Mark
On Tue, Dec 16, 2014 at 10:57 AM, Brett Cannon br...@python.org wrote:
Mark, your tone is no longer constructive and is hurting your case in
arguing for anything. Please take it down a notch.
On Tue Dec 16 2014 at 1:48:59 PM Mark Roberts wiz...@gmail.com wrote:
On Tue, Dec 16, 2014 at 2:45 AM, Antoine Pitrou solip...@pitrou.net
wrote:
Iterating accross a dictionary doesn't need compatibility shims. It's
dead simple in all Python versions:
$ python2
Python 2.7.8 (default, Oct 20 2014, 15:05:19)
[GCC 4.9.1] on linux2
Type help, copyright, credits or license for more information.
d = {'a': 1}
for k in d: print(k)
...
a
$ python3
Python 3.4.2 (default, Oct 8 2014, 13:08:17)
[GCC 4.9.1] on linux
Type help, copyright, credits or license for more information.
d = {'a': 1}
for k in d: print(k)
...
a
Besides, using iteritems() and friends is generally a premature
optimization, unless you know you'll have very large containers.
Creating a list is cheap.
It seems to me that every time I hear this, the author is basically
admitting that Python is a toy language not meant for serious computing
(where serious is defined in extremely modest terms). The advice is also
very contradictory to literally every talk on performant Python that I've
seen at PyCon or PyData or ... well, anywhere. And really, doesn't it
strike you as incredibly presumptuous to call the *DEFAULT BEHAVIOR* of
Python 3 a premature optimization? Isn't the whole reason that the
default behavior switch was made is because creating lists willy nilly all
over the place really *ISN'T* cheap? This isn't the first time someone has
tried to run this line past me, but it's the first time I've been fed up
enough with the topic to call it complete BS on the spot. Please help me
stop the community at large from saying this, because it really isn't true
at all.
-Mark
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: https://mail.python.org/mailman/options/python-dev/
brett%40python.org
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.x and 3.x use survey, 2014 edition
On Tue, 16 Dec 2014 19:25:35 + Brett Cannon br...@python.org wrote: As for the changing of the default in Python 3, that's because we decided to make iterators the default everywhere. And that was mostly for consistency, not performance reasons. It was also for flexibility as you can go from an iterator to a list by just wrapping the iterator in list(), but you can't go the other way around. And two other reasons: - the API becomes simpler to use as there's no need to choose between .items() and .iteritems(), etc. - the 3.x methods don't return iterators but views, which have set-like features in addition to basic iterating Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.x and 3.x use survey, 2014 edition
Mark Roberts wiz...@gmail.com: it's outright insulting to be told my complaints about writing 2/3 compatible code are invalid on the basis of premature optimization. IMO, you should consider forking your library code for Python2 and Python3. The multidialect code will look unidiomatic for each dialect. When the critical mass favors Python3 (possibly within a couple of years), the transition will be as total and quick as from VHS to DVDs. At that point, a multidialect library would seem quaint, while a separate Python2 fork can simply be left behind (bug fixes only). Marko ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.x and 3.x use survey, 2014 edition
On Tue, Dec 16, 2014 at 1:58 PM, Marko Rauhamaa ma...@pacujo.net wrote: IMO, you should consider forking your library code for Python2 and Python3. I don't get the idea that Brett Cannon agrees with you: http://nothingbutsnark.svbtle.com/commentary-on-getting-your-code-to-run-on-python-23 While he doesn't explicitly say so, I got the distinct impression reading his recent blog post that he supports one source, not forked sources. In the absence to evidence to the contrary, I think of Brett as the most expert developer in the porting space. Skip ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.x and 3.x use survey, 2014 edition
On Tue, Dec 16, 2014 at 2:15 PM, Skip Montanaro skip.montan...@gmail.com wrote: On Tue, Dec 16, 2014 at 1:58 PM, Marko Rauhamaa ma...@pacujo.net wrote: IMO, you should consider forking your library code for Python2 and Python3. I don't get the idea that Brett Cannon agrees with you: http://nothingbutsnark.svbtle.com/commentary-on-getting-your-code-to-run-on-python-23 While he doesn't explicitly say so, I got the distinct impression reading his recent blog post that he supports one source, not forked sources. In the absence to evidence to the contrary, I think of Brett as the most expert developer in the porting space. I'm a few inches shorter than Brett, but having done several sizable ports, dual-source has never even on the table. I would prefer the run 2to3 at installation time option before maintaining two versions (which I do not prefer at all in reality). ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] datetime nanosecond support (ctd?)
On Tue, Dec 16, 2014 at 12:10 PM, matthieu bec m...@gmto.org wrote: I wonder if the datetime module is really the right location, that has constructor(year, month, day, ..., second, microsecond) - with 0ms99, no millis. adding 0ns999 would seem quite ugly, in fact nothing looks quite right. We can make nanosecond a keyword-only argument, so that time(1, 2, 3, nanosecond=123456789) - 01:02:03.123456789 and time(1, 2, 3, 4, nanosecond=123456789) - error Users will probably be encouraged to avoid positional form when specifying time to subsecond precision. I would say time(1, 2, 3, microsecond=4) is clearer than time(1, 2, 3, 4) anyways. Another option is to allow float for the second argument: time(1, 2, 3.123456789) - 01:02:03.123456789 ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.x and 3.x use survey, 2014 edition
Brian Curtin br...@python.org: I'm a few inches shorter than Brett, but having done several sizable ports, dual-source has never even on the table. I would prefer the run 2to3 at installation time option before maintaining two versions (which I do not prefer at all in reality). How about run 3to2 at installation time? Marko ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.x and 3.x use survey, 2014 edition
On Tue, Dec 16, 2014 at 3:03 PM, Marko Rauhamaa ma...@pacujo.net wrote: How about run 3to2 at installation time? In theory, yes, but that's not a fork either. Skip ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Python 3.4.2/ PyGame Registry
Good Morning, I installed Python 3.4.2 on my work computer. I was looking at the book Head First Programming which references download PYGAME. I downloaded what I believe to be the correct version and it tells me that I don't see the installer. I look in the registry and there is no: *HKEY_CURRENT_USER\Software\Python\* Did I do something wrong? This is all new to me. Any help would be greatly appreciated. Thanks Matt [image: Inline image 1] ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.x and 3.x use survey, 2014 edition
On 12/16/2014 11:25 AM, Brett Cannon wrote: What Antoine said is not patently false [...] What Antoine said was: Unless you have a lot of network-facing code, writing 2/3 compatible code should actually be quite pedestrian. Or, to paraphrase slightly, if you aren't writing network code, and your 2/3 code is painful, you must be doing something wrong! That may not be what he intended, but that is certainly how it felt. -- ~Ethan~ signature.asc Description: OpenPGP digital signature ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.x and 3.x use survey, 2014 edition
On 12/16/2014 12:31 PM, Brian Curtin wrote: On Tue, Dec 16, 2014 at 2:15 PM, Skip Montanaro wrote: On Tue, Dec 16, 2014 at 1:58 PM, Marko Rauhamaa wrote: IMO, you should consider forking your library code for Python2 and Python3. I don't get the idea that Brett Cannon agrees with you: http://nothingbutsnark.svbtle.com/commentary-on-getting-your-code-to-run-on-python-23 While he doesn't explicitly say so, I got the distinct impression reading his recent blog post that he supports one source, not forked sources. In the absence to evidence to the contrary, I think of Brett as the most expert developer in the porting space. I'm a few inches shorter than Brett, but having done several sizable ports, dual-source has never even on the table. I would prefer the run 2to3 at installation time option before maintaining two versions (which I do not prefer at all in reality). I have a handful of projects. The tiny ones are one-source, the biggest one (dbf) is not. If I had an entire application I would probably split the difference, and just have dual source on a single module to hold the classes/functions that absolutely-had-to-have-this-or-that-feature (exec (the statement) vs exec (the function) comes to mind). -- ~Ethan~ signature.asc Description: OpenPGP digital signature ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.x and 3.x use survey, 2014 edition
This thread hasn't been productive for a really long time now. On Tue, Dec 16, 2014 at 1:52 PM, Ethan Furman et...@stoneleaf.us wrote: On 12/16/2014 12:31 PM, Brian Curtin wrote: On Tue, Dec 16, 2014 at 2:15 PM, Skip Montanaro wrote: On Tue, Dec 16, 2014 at 1:58 PM, Marko Rauhamaa wrote: IMO, you should consider forking your library code for Python2 and Python3. I don't get the idea that Brett Cannon agrees with you: http://nothingbutsnark.svbtle.com/commentary-on-getting-your-code-to-run-on-python-23 While he doesn't explicitly say so, I got the distinct impression reading his recent blog post that he supports one source, not forked sources. In the absence to evidence to the contrary, I think of Brett as the most expert developer in the porting space. I'm a few inches shorter than Brett, but having done several sizable ports, dual-source has never even on the table. I would prefer the run 2to3 at installation time option before maintaining two versions (which I do not prefer at all in reality). I have a handful of projects. The tiny ones are one-source, the biggest one (dbf) is not. If I had an entire application I would probably split the difference, and just have dual source on a single module to hold the classes/functions that absolutely-had-to-have-this-or-that-feature (exec (the statement) vs exec (the function) comes to mind). -- ~Ethan~ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/guido%40python.org -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.x and 3.x use survey, 2014 edition
On Dec 16, 2014, at 02:15 PM, Skip Montanaro wrote: While he doesn't explicitly say so, I got the distinct impression reading his recent blog post that he supports one source, not forked sources. I've ported a fair bit of code, both pure-Python and C extensions, both libraries and applications. For successful library ports to Python 3 that need to remain Python 2 compatible, I would almost always recommend a single source, common dialect, no-2to3 approach. There may be exceptions, but this strategy has proven effective over and over. I generally find I don't need `six` but it does provide some nice conveniences that can be helpful. With something like tox running your test suite, it doesn't even have to be painful to maintain. Cheers, -Barry ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3.4.2/ PyGame Registry
This mailing list is for the development OF Python, not its use. You should be able to get help on the python-tutor or Python - list mailing lists. On Tue, Dec 16, 2014, 16:42 Matthew Braun matth...@perfumania.com wrote: Good Morning, I installed Python 3.4.2 on my work computer. I was looking at the book Head First Programming which references download PYGAME. I downloaded what I believe to be the correct version and it tells me that I don't see the installer. I look in the registry and there is no: *HKEY_CURRENT_USER\Software\Python\* Did I do something wrong? This is all new to me. Any help would be greatly appreciated. Thanks Matt [image: Inline image 1] ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/ brett%40python.org ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] datetime nanosecond support (ctd?)
Maybe what I meant with `nothing looks quite right': seconds as float, microseconds as float, nanosecond as 0..999, nanoseconds as 0..9 with mandatory keyword that precludes microseconds - all can be made to work, none seems completely satisfying. In fact, I don't really have a use for it from python - but something would be needed in C for the implementation of datetime.from_timespec and time.from_timespec that calls the constructor PyObjectCall_CallFunction(clas,...,...) - can this happen and remain hidden from the python layer? Regards, Matthieu On 12/16/14 12:45 PM, Alexander Belopolsky wrote: On Tue, Dec 16, 2014 at 12:10 PM, matthieu bec m...@gmto.org mailto:m...@gmto.org wrote: I wonder if the datetime module is really the right location, that has constructor(year, month, day, ..., second, microsecond) - with 0ms99, no millis. adding 0ns999 would seem quite ugly, in fact nothing looks quite right. We can make nanosecond a keyword-only argument, so that time(1, 2, 3, nanosecond=123456789) - 01:02:03.123456789 and time(1, 2, 3, 4, nanosecond=123456789) - error Users will probably be encouraged to avoid positional form when specifying time to subsecond precision. I would say time(1, 2, 3, microsecond=4) is clearer than time(1, 2, 3, 4) anyways. Another option is to allow float for the second argument: time(1, 2, 3.123456789) - 01:02:03.123456789 ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/mdcb808%40gmail.com -- Matthieu BecGMTO Corp cell : +1 626 425 7923 251 S Lake Ave, Suite 300 phone: +1 626 204 0527 Pasadena, CA 91101 ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] datetime nanosecond support (ctd?)
On 12/16/14 3:28 PM, Matthieu Bec wrote: Maybe what I meant with `nothing looks quite right': seconds as float, microseconds as float, nanosecond as 0..999, nanoseconds as 0..9 with mandatory keyword that precludes microseconds - all can be made to work, none seems completely satisfying. In fact, I don't really have a use for it from python - but something would be needed in C for the implementation of datetime.from_timespec and time.from_timespec that calls the constructor that's the datetime.time.from_timespec btw. PyObjectCall_CallFunction(clas,...,...) - can this happen and remain hidden from the python layer? Regards, Matthieu On 12/16/14 12:45 PM, Alexander Belopolsky wrote: On Tue, Dec 16, 2014 at 12:10 PM, matthieu bec m...@gmto.org mailto:m...@gmto.org wrote: I wonder if the datetime module is really the right location, that has constructor(year, month, day, ..., second, microsecond) - with 0ms99, no millis. adding 0ns999 would seem quite ugly, in fact nothing looks quite right. We can make nanosecond a keyword-only argument, so that time(1, 2, 3, nanosecond=123456789) - 01:02:03.123456789 and time(1, 2, 3, 4, nanosecond=123456789) - error Users will probably be encouraged to avoid positional form when specifying time to subsecond precision. I would say time(1, 2, 3, microsecond=4) is clearer than time(1, 2, 3, 4) anyways. Another option is to allow float for the second argument: time(1, 2, 3.123456789) - 01:02:03.123456789 ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/mdcb808%40gmail.com -- Matthieu BecGMTO Corp cell : +1 626 425 7923 251 S Lake Ave, Suite 300 phone: +1 626 204 0527 Pasadena, CA 91101 ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] datetime nanosecond support (ctd?)
Nothing looks quite right is a common phenomenon when you're constrained by backward compatibility. The perfect solution would throw away compatibility, but that has its own downsides. So just go for what looks the least wrong. On Tue, Dec 16, 2014 at 3:28 PM, Matthieu Bec m...@gmto.org wrote: Maybe what I meant with `nothing looks quite right': seconds as float, microseconds as float, nanosecond as 0..999, nanoseconds as 0..9 with mandatory keyword that precludes microseconds - all can be made to work, none seems completely satisfying. In fact, I don't really have a use for it from python - but something would be needed in C for the implementation of datetime.from_timespec and time.from_timespec that calls the constructor PyObjectCall_CallFunction(clas,...,...) - can this happen and remain hidden from the python layer? Regards, Matthieu On 12/16/14 12:45 PM, Alexander Belopolsky wrote: On Tue, Dec 16, 2014 at 12:10 PM, matthieu bec m...@gmto.org mailto:m...@gmto.org wrote: I wonder if the datetime module is really the right location, that has constructor(year, month, day, ..., second, microsecond) - with 0ms99, no millis. adding 0ns999 would seem quite ugly, in fact nothing looks quite right. We can make nanosecond a keyword-only argument, so that time(1, 2, 3, nanosecond=123456789) - 01:02:03.123456789 and time(1, 2, 3, 4, nanosecond=123456789) - error Users will probably be encouraged to avoid positional form when specifying time to subsecond precision. I would say time(1, 2, 3, microsecond=4) is clearer than time(1, 2, 3, 4) anyways. Another option is to allow float for the second argument: time(1, 2, 3.123456789) - 01:02:03.123456789 ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/ mdcb808%40gmail.com -- Matthieu BecGMTO Corp cell : +1 626 425 7923 251 S Lake Ave, Suite 300 phone: +1 626 204 0527 Pasadena, CA 91101 ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/ guido%40python.org -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] datetime nanosecond support (ctd?)
python-n (for next) - just poking fun at the other thread On 12/16/14 4:17 PM, Guido van Rossum wrote: Nothing looks quite right is a common phenomenon when you're constrained by backward compatibility. The perfect solution would throw away compatibility, but that has its own downsides. So just go for what looks the least wrong. On Tue, Dec 16, 2014 at 3:28 PM, Matthieu Bec m...@gmto.org mailto:m...@gmto.org wrote: Maybe what I meant with `nothing looks quite right': seconds as float, microseconds as float, nanosecond as 0..999, nanoseconds as 0..9 with mandatory keyword that precludes microseconds - all can be made to work, none seems completely satisfying. In fact, I don't really have a use for it from python - but something would be needed in C for the implementation of datetime.from_timespec and time.from_timespec that calls the constructor PyObjectCall_CallFunction(__clas,...,...) - can this happen and remain hidden from the python layer? Regards, Matthieu On 12/16/14 12:45 PM, Alexander Belopolsky wrote: On Tue, Dec 16, 2014 at 12:10 PM, matthieu bec m...@gmto.org mailto:m...@gmto.org mailto:m...@gmto.org mailto:m...@gmto.org wrote: I wonder if the datetime module is really the right location, that has constructor(year, month, day, ..., second, microsecond) - with 0ms99, no millis. adding 0ns999 would seem quite ugly, in fact nothing looks quite right. We can make nanosecond a keyword-only argument, so that time(1, 2, 3, nanosecond=123456789) - 01:02:03.123456789 and time(1, 2, 3, 4, nanosecond=123456789) - error Users will probably be encouraged to avoid positional form when specifying time to subsecond precision. I would say time(1, 2, 3, microsecond=4) is clearer than time(1, 2, 3, 4) anyways. Another option is to allow float for the second argument: time(1, 2, 3.123456789 tel:3.123456789) - 01:02:03.123456789 _ Python-Dev mailing list Python-Dev@python.org mailto:Python-Dev@python.org https://mail.python.org/__mailman/listinfo/python-dev https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/__mailman/options/python-dev/__mdcb808%40gmail.com https://mail.python.org/mailman/options/python-dev/mdcb808%40gmail.com -- Matthieu BecGMTO Corp cell : +1 626 425 7923 tel:%2B1%20626%20425%207923 251 S Lake Ave, Suite 300 phone: +1 626 204 0527 tel:%2B1%20626%20204%200527 Pasadena, CA 91101 _ Python-Dev mailing list Python-Dev@python.org mailto:Python-Dev@python.org https://mail.python.org/__mailman/listinfo/python-dev https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/__mailman/options/python-dev/__guido%40python.org https://mail.python.org/mailman/options/python-dev/guido%40python.org -- --Guido van Rossum (python.org/~guido http://python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/mdcb808%40gmail.com -- Matthieu BecGMTO Corp cell : +1 626 425 7923 251 S Lake Ave, Suite 300 phone: +1 626 204 0527 Pasadena, CA 91101 ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] datetime nanosecond support (ctd?)
On 12/16/14 3:31 PM, Matthieu Bec wrote: On 12/16/14 3:28 PM, Matthieu Bec wrote: Maybe what I meant with `nothing looks quite right': seconds as float, microseconds as float, nanosecond as 0..999, nanoseconds as 0..9 with mandatory keyword that precludes microseconds - all can be made to work, none seems completely satisfying. In fact, I don't really have a use for it from python - but something would be needed in C for the implementation of datetime.from_timespec and time.from_timespec that calls the constructor that's the datetime.time.from_timespec btw. datetime.time.from_timespec actually makes no sense. PyObjectCall_CallFunction(clas,...,...) - can this happen and remain hidden from the python layer? ... occured to me I might simply create a us datetime object and set its nanofield after. I'll try wrap up a recap proposal later. Regards, Matthieu ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.x and 3.x use survey, 2014 edition
On 12/16/2014 03:09 AM, Barry Warsaw wrote: On Dec 16, 2014, at 02:15 PM, Skip Montanaro wrote: While he doesn't explicitly say so, I got the distinct impression reading his recent blog post that he supports one source, not forked sources. I've ported a fair bit of code, both pure-Python and C extensions, both libraries and applications. For successful library ports to Python 3 that need to remain Python 2 compatible, I would almost always recommend a single source, common dialect, no-2to3 approach. There may be exceptions, but this strategy has proven effective over and over. I generally find I don't need `six` but it does provide some nice conveniences that can be helpful. With something like tox running your test suite, it doesn't even have to be painful to maintain. I'll agree; with tox and some automated CI system like travis or jenkins or whatever, once you've done the port, it's only a minor nuisance to maintain a straddled 2/3 codebase. Programming in only the subset still isn't much fun, but maintenance is slightly easier than I expected it to be. Drive by contributions become slightly harder to accept because they often break 3 compatibility, and contributors are often unable or unwilling to install all the required versions that are tested by tox. - C ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.x and 3.x use survey, 2014 edition
On 17 December 2014 at 10:45, Chris McDonough chr...@plope.com wrote: On 12/16/2014 03:09 AM, Barry Warsaw wrote: On Dec 16, 2014, at 02:15 PM, Skip Montanaro wrote: While he doesn't explicitly say so, I got the distinct impression reading his recent blog post that he supports one source, not forked sources. I've ported a fair bit of code, both pure-Python and C extensions, both libraries and applications. For successful library ports to Python 3 that need to remain Python 2 compatible, I would almost always recommend a single source, common dialect, no-2to3 approach. There may be exceptions, but this strategy has proven effective over and over. I generally find I don't need `six` but it does provide some nice conveniences that can be helpful. With something like tox running your test suite, it doesn't even have to be painful to maintain. I'll agree; with tox and some automated CI system like travis or jenkins or whatever, once you've done the port, it's only a minor nuisance to maintain a straddled 2/3 codebase. Programming in only the subset still isn't much fun, but maintenance is slightly easier than I expected it to be. Drive by contributions become slightly harder to accept because they often break 3 compatibility, and contributors are often unable or unwilling to install all the required versions that are tested by tox. It's worth noting that the last problem can potentially be mitigated to some degree by taking advantage of the new pylint --py3k feature making it easier to check that code is 2/3 source compatible without needing a local copy of Python 3 to test against, and without needing to adhere to pylint's other checks. As far as Marko's suggestion of maintaining two code bases go, that's what we do for the standard library, and we've *never* advised anyone else to do the same. Even before experience showed the source compatible approach was more practical, the original advice to third party developers was to use 2to3 to automatically derive the Python 3 version from the Python 2 version and address any compatibility issues by modifying the Python 2 sources. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
