Paul Rubin writes:
> Ben Finney writes:
> > The point, one more time with feeling, is that the incompatibilities
> > between 2.x and 3.x will *increase* over time.
>
> The issue is less the "incompatibilities" than the -backwards-
> incompatibilities.
Yes, that's what I meant. Python 3 is delib
On Wed, Jul 7, 2010 at 10:55 PM, Carl Banks wrote:
> On Jul 7, 1:31 am, Paul McGuire wrote:
>> On Jul 6, 3:30 am, David Cournapeau wrote:> On Tue, Jul
>> 6, 2010 at 4:30 AM, D'Arcy J.M. Cain wrote:
>>
>> > One thing that would be very useful is how to maintain something that
>> > works on 2.x
The code below, very much work in progress, just trying things, is C++.
Sorry about the formatting, I had to reformat manually for this posting:
class Module
{
private:
Ptr p_;
public:
Module( PyModuleDef const& def )
: p_( ::PyModule_Create( co
On 7/7/2010 5:29 AM, geremy condra wrote:
On Tue, Jul 6, 2010 at 1:37 AM, Terry Reedy wrote:
On 7/5/2010 9:00 PM, Philip Semanchuk wrote:
On Jul 5, 2010, at 6:41 PM, Chris Rebert wrote:
On Mon, Jul 5, 2010 at 3:38 PM, Philip Semanchu
I ported two pure C extensions from 2 to 3 and was even
geremy condra writes:
> On Wed, Jul 7, 2010 at 9:14 PM, Ben Finney wrote:
> > [backward-]incompatibilities between 2.x and 3.x will *increase*
> > over time.
>
> ...and? I don't get to use features from 2.7, why would I expect to
> use features from 3.3?
Conversely, why would you support Python
I'm starting to think that one should use Decimals by default and
reserve floats for special cases.
This is somewhat analogous to the way that Python provides
arbitrarily-big integers by default and Python programmers only use
old-fashioned fixed-size integers for special cases, such as
interopera
On Wed, Jul 7, 2010 at 9:10 PM, Martin v. Loewis wrote:
>
> My preferred long-term solution is to reduce the usage of the C library
> in CPython as much as reasonable, atleast on Windows. Memory management
> could directly use the heap functions (or even more directly
> VirtualAlloc); filenos cou
On 7/7/2010 4:31 AM, Paul McGuire wrote:
[snip interesting report on how Paul suppost pyparsing for 2.3 to 3.1]
Thank you for this.
Do you think such cross-version support would have been easier or harder
if the major changes and deletions in 3.0 has been spread over several
versions, such as
Ben Finney writes:
>> On the other hand, the door appears closed for Python 3 adding more
>> stuff that breaks Python 2 code.
>
> What gives you that idea? Can you reference a specific statement from
> the PYthon developers that says that?
It's just logic. As I understand it, future versions of
On Wed, Jul 7, 2010 at 11:32 PM, Ben Finney wrote:
> geremy condra writes:
>
>> On Wed, Jul 7, 2010 at 9:14 PM, Ben Finney
>> wrote:
>> > [backward-]incompatibilities between 2.x and 3.x will *increase*
>> > over time.
>>
>> ...and? I don't get to use features from 2.7, why would I expect to
>>
On 7/7/2010 9:14 PM, Ben Finney wrote:
The point, one more time with feeling, is that the incompatibilities
between 2.x and 3.x will *increase* over time.
For the purpose of maintaining least-common-denominator multi-version
code, it is only deletions and semantic changes that matter. Feature
On Thu, Jul 8, 2010 at 5:41 AM, Zooko O'Whielacronx wrote:
> I'm starting to think that one should use Decimals by default and
> reserve floats for special cases.
>
> This is somewhat analogous to the way that Python provides
> arbitrarily-big integers by default and Python programmers only use
>
Dear Paul McGuire:
Thank you very much for these notes!
See also a few other notes:
Michael Foord:
http://www.voidspace.org.uk/python/weblog/arch_d7_2010_03_20.shtml#e1167
Ned Batchelder:
http://nedbatchelder.com/blog/200910/running_the_same_code_on_python_2x_and_3x.html
I was wondering if it
On 7/7/2010 10:49 PM, Ben Finney wrote:
Yes, that's what I meant. Python 3 is deliberately under no obligation
to support code that works in Python 2. If something needs fixing, and
that fix would involve breaking Python 2 code, then that's not a
consideration any more.
Code that works in 3.1
> I saw you already mentioned work toward this a few months (years ?)
> ago. Is there some kind of roadmap, or could you use some help ? I
> would really like to solve this issue as much as we possibly can,
Well, Python 3 has already dropped stdio for its own io library, and
I do want to get rid o
On Wed, Jul 7, 2010 at 10:04 PM, David Cournapeau wrote:
>
> Decimal vs float is a different matter altogether: decimal has
> downsides compared to float. First, there is this irreconcilable fact
> that no matter how small your range is, it is impossible to represent
> exactly all (even most) numb
Am 07.07.2010 23:10, schrieb Brendan Abel:
One thing that would be very useful is how to maintain something that
works on 2.x and 3.x, but not limiting yourself to 2.6. Giving up
versions below 2.6 is out of the question for most projects with a
significant userbase IMHO. As suc
On Jul 7, 10:55 pm, Carl Banks wrote:
> On Jul 7, 1:31 am, Paul McGuire wrote:
> > I just
> > couldn't get through on the python-dev list that I couldn't just
> > upgrade my code to 2.6 and then use 2to3 to keep in step across the
> > 2-3 chasm, as this would leave behind my faithful pre-2.6 user
> Python 3.x will continue to change. The incompatibilities between 3.x
> and 2.x will only become more numerous. If your goal is to support
> 2.x, and 3.x, you'd be best supporting them separately.
I don't think that's a particularly good approach. Having a single code
base for both likely redu
> The point, one more time with feeling, is that the incompatibilities
> between 2.x and 3.x will *increase* over time.
I think this is unfounded, and actually false.
Instead, the incompatibilities will *decrease* over the next few years.
Suppose you support 2.x and 3.x from a single code base. T
Am 08.07.2010 04:17, schrieb imageguy:
>
>> I, too, have multiple versions installed -- newer ones for running code
>> I haven't upgraded; older ones for compatibility testing where needed.
>> I just install to the default c:\pythonxy directories (although I like
>> the idea of a common root) and
> And since things work for a single method when I declare 'def' as
> 'static', I suspect that means that the function object created by
> PyCFunction_NewEx holds on to a pointer to the PyMethodDef structure?
Correct; it doesn't make a copy of the struct. So when you want the
function object to ou
On 7/7/10 9:46 PM, "Martin v. Löwis" wrote:
>> I saw you already mentioned work toward this a few months (years ?)
>> ago. Is there some kind of roadmap, or could you use some help ? I
>> would really like to solve this issue as much as we possibly can,
>
> Well, Python 3 has already dropped stdio
Stephen Hansen wrote:
> You're doing string formatting
> to construct your SQL, which is where the trouble comes from.
You're wasting your breath, this topic has been discussed ad nauseum
with Victor for well over a year now. He appears to be teaching
himself relational db based web-development w
> I just
> couldn't get through on the python-dev list that I couldn't just
> upgrade my code to 2.6 and then use 2to3 to keep in step across the
> 2-3 chasm, as this would leave behind my faithful pre-2.6 users.
Not sure whom you had been talking to. But I would have tried to explain
that you don
* Martin v. Loewis, on 08.07.2010 07:23:
And since things work for a single method when I declare 'def' as
'static', I suspect that means that the function object created by
PyCFunction_NewEx holds on to a pointer to the PyMethodDef structure?
Correct; it doesn't make a copy of the struct. So w
101 - 126 of 126 matches
Mail list logo
