Re: [Python-Dev] Python 2.x and 3.x use survey, 2014 edition

2014-12-16 Thread Antoine Pitrou
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

Re: [Python-Dev] Python 2.x and 3.x use survey, 2014 edition

2014-12-16 Thread Petr Viktorin
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

Re: [Python-Dev] datetime nanosecond support (ctd?)

2014-12-16 Thread matthieu bec
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

Re: [Python-Dev] Python 2.x and 3.x use survey, 2014 edition

2014-12-16 Thread Mark Roberts
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

Re: [Python-Dev] Python 2.x and 3.x use survey, 2014 edition

2014-12-16 Thread Brett Cannon
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

Re: [Python-Dev] Python 2.x and 3.x use survey, 2014 edition

2014-12-16 Thread Mark Roberts
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

Re: [Python-Dev] datetime nanosecond support (ctd?)

2014-12-16 Thread Skip Montanaro
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

Re: [Python-Dev] Python 2.x and 3.x use survey, 2014 edition

2014-12-16 Thread R. David Murray
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

Re: [Python-Dev] datetime nanosecond support (ctd?)

2014-12-16 Thread Guido van Rossum
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

Re: [Python-Dev] datetime nanosecond support (ctd?)

2014-12-16 Thread Matthieu Bec
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

Re: [Python-Dev] datetime nanosecond support (ctd?)

2014-12-16 Thread Guido van Rossum
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,

Re: [Python-Dev] Python 2.x and 3.x use survey, 2014 edition

2014-12-16 Thread Brett Cannon
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

Re: [Python-Dev] Python 2.x and 3.x use survey, 2014 edition

2014-12-16 Thread Antoine Pitrou
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

Re: [Python-Dev] Python 2.x and 3.x use survey, 2014 edition

2014-12-16 Thread Marko Rauhamaa
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

Re: [Python-Dev] Python 2.x and 3.x use survey, 2014 edition

2014-12-16 Thread Skip Montanaro
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

Re: [Python-Dev] Python 2.x and 3.x use survey, 2014 edition

2014-12-16 Thread Brian Curtin
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:

Re: [Python-Dev] datetime nanosecond support (ctd?)

2014-12-16 Thread Alexander Belopolsky
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

Re: [Python-Dev] Python 2.x and 3.x use survey, 2014 edition

2014-12-16 Thread Marko Rauhamaa
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

Re: [Python-Dev] Python 2.x and 3.x use survey, 2014 edition

2014-12-16 Thread Skip Montanaro
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

[Python-Dev] Python 3.4.2/ PyGame Registry

2014-12-16 Thread Matthew Braun
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:

Re: [Python-Dev] Python 2.x and 3.x use survey, 2014 edition

2014-12-16 Thread Ethan Furman
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,

Re: [Python-Dev] Python 2.x and 3.x use survey, 2014 edition

2014-12-16 Thread Ethan Furman
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:

Re: [Python-Dev] Python 2.x and 3.x use survey, 2014 edition

2014-12-16 Thread Guido van Rossum
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:

Re: [Python-Dev] Python 2.x and 3.x use survey, 2014 edition

2014-12-16 Thread Barry Warsaw
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.

Re: [Python-Dev] Python 3.4.2/ PyGame Registry

2014-12-16 Thread Brett Cannon
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

Re: [Python-Dev] datetime nanosecond support (ctd?)

2014-12-16 Thread Matthieu Bec
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

Re: [Python-Dev] datetime nanosecond support (ctd?)

2014-12-16 Thread Matthieu Bec
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

Re: [Python-Dev] datetime nanosecond support (ctd?)

2014-12-16 Thread Guido van Rossum
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:

Re: [Python-Dev] datetime nanosecond support (ctd?)

2014-12-16 Thread Matthieu Bec
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

Re: [Python-Dev] datetime nanosecond support (ctd?)

2014-12-16 Thread Matthieu Bec
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

Re: [Python-Dev] Python 2.x and 3.x use survey, 2014 edition

2014-12-16 Thread Chris McDonough
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

Re: [Python-Dev] Python 2.x and 3.x use survey, 2014 edition

2014-12-16 Thread Nick Coghlan
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,