On 17 December 2014 at 10:45, Chris McDonough 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 fo
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
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 m
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 jus
"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 wrote:
>
>
> Maybe wh
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 satisfyin
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 fo
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 wrote:
> Good Morning,
> I installed Python 3.4.2 on my work computer. I was looking at the book
> "Head
This thread hasn't been productive for a really long time now.
On Tue, Dec 16, 2014 at 1:52 PM, Ethan Furman 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:
> >>>
> >>> IM
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.
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
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
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_CURR
On Tue, Dec 16, 2014 at 3:03 PM, Marko Rauhamaa 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-
Brian Curtin :
> 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 i
On Tue, Dec 16, 2014 at 12:10 PM, matthieu bec wrote:
> I wonder if the datetime module is really the right location, that has
> constructor(year, month, day, ..., second, microsecond) - with 0 no millis. adding 0 quite right.
We can make nanosecond a keyword-only argument, so that
time(1, 2,
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.co
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
Mark Roberts :
> 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.
Whe
On Tue, 16 Dec 2014 19:25:35 +
Brett Cannon 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 iter
On Tue Dec 16 2014 at 2:05:28 PM Mark Roberts 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
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
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
I vote to copy Ruby's %N and leave %f alone.
On Tue, Dec 16, 2014 at 11:08 AM, Skip Montanaro
wrote:
>
>
> On Tue, Dec 16, 2014 at 11:10 AM, matthieu bec wrote:
> > Agreed with Antoine, strftime/strptime are somewhat different concerns.
> > Doesn't mean thay cannot be fixed at the same time but
On Tue, 16 Dec 2014 10:48:07 -0800, Mark Roberts wrote:
> On Tue, Dec 16, 2014 at 2:45 AM, Antoine Pitrou 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
On Tue, Dec 16, 2014 at 11:10 AM, matthieu bec 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 trac
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
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 wrote:
> On Tue, Dec 16, 2014 at 2:45 AM, Antoine Pitrou
> wrote:
>>
>> Iterating accross a dictionary doesn't need compatibilit
On Tue, Dec 16, 2014 at 2:45 AM, Antoine Pitrou 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 "lic
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-b
On Sun, Dec 14, 2014 at 1:14 AM, Nick Coghlan 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
On Mon, 15 Dec 2014 19:08:17 -0800
Mark Roberts 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 c
32 matches
Mail list logo
