Paul McGuire <[EMAIL PROTECTED]> writes:
> I see that there is some movement to "get rid of bound methods," but
> I don't fully understand how this will be done, nor how I will
> adjust my code to compensate.
Isn't it supposed to get rid of *un*bound methods? That is,
Class.method will simply re
> Well, my concerns about 3.0 continue to be founded. Up until now I
> have been just reading "What's New" docs, and relying on input from
> others as to what changes I will have to make. Yesterday I downloaded
> and installed 3.0a5, and it is clear that there is *no* way to have a
> single code
On Apr 24, 9:21 am, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > Again, to me, this is a non-issue because I've been able to create a
> > cross-version compatible single codebase for pyparsing. But it was a
> > bit dicey there for a while, and I think other module developers/
> > maintainers m
> Unless I mix my psuedodicts with standard dicts
> in the same list, for example, or pass them to
> functions intended to accept any dict-like object,
> including the especially important case of standard
> dicts.
>
> Who knows? Maybe I'm wrong about this being a much of
> problem.
I think so.
Aaron Watters <[EMAIL PROTECTED]> writes:
> I think it's outrageous to change the basic usage for things like
> dictionary.keys() when it would be so easy to leave the old
> definition and add a new method like dictionary.keySet().
Except that name would be outrageously non-conformant with PEP 8.
On Apr 27, 9:18 pm, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> An existing application of an existing dict-like
> object will continue to work just fine in Python 3,
> right?
Unless I mix my psuedodicts with standard dicts
in the same list, for example, or pass them to
functions intended to a
> This would save me personally a great deal of
> painful tedium, I suspect (especially considering
> that I've implemented a lot of "dictionary-like"
> objects -- so I'll have to change the way their
> "keys" method works -- or something -- I haven't
> figured it out yet...).
[...]
> In C# and jav
> shame
> 1 a. a painful emotion caused by consciousness of guilt,
> shortcoming, or impropriety
> 2 a condition of humiliating disgrace or disrepute
Sigh. This is stupid (in the usual usage), but
I must reply because I can't control myself. I meant
usage 5:
"something regrettable, unfort
In article <[EMAIL PROTECTED]>,
"Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > I still think it's a shame
> [...]
> > pps: I have to note that it would be nice if the
> > ad-hominem (sp?) invective would drop out of
> > these threads -- it doesn't add a lot, I think.
>
> shame
> 1 a. a p
En Thu, 24 Apr 2008 11:10:55 -0300, Paul McGuire <[EMAIL PROTECTED]>
escribió:
On Apr 21, 9:01 pm, "Gabriel Genellina" <[EMAIL PROTECTED]>
wrote:
Perhaps you can manage to keep your code compatible with all versions,
but
AFAIK the reccomended strategy is to write code compatible with Pyt
> In my view using a conversion tool on an ongoing basis is
> not an option. It just adds a dependancy. What happens when
> the conversion tool is upgraded in a non-backwards-compatible
> way? Or do we have assurance that it won't be ;)?
The latter: if you include a copy of the converter with y
"Aaron Watters" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
The reason that successive versions of 2.x broke so little is that starting
at about 2.2, all breakages (starting with int division change) were put
off until until 3.0 instead of being implemented as decided upon (wit
On Apr 24, 10:10 am, Paul McGuire <[EMAIL PROTECTED]> wrote
> end point applications (I consider maintaining 2 branches to be in the
> "not working" category), but it does NOT WORK for people who maintain
> modules for other people to use, because those people may be on a
> range of Python versions
> Again, to me, this is a non-issue because I've been able to create a
> cross-version compatible single codebase for pyparsing. But it was a
> bit dicey there for a while, and I think other module developers/
> maintainers may not be so lucky.
I'm more optimistic. I tried it for Django, and whil
On Apr 21, 9:01 pm, "Gabriel Genellina" <[EMAIL PROTECTED]>
wrote:
>
> Perhaps you can manage to keep your code compatible with all versions, but
> AFAIK the reccomended strategy is to write code compatible with Python 2.6
> and use the 2to3 tool to generate the 3.0 source. And *not* edit the 3
"Martin v. Löwis" <[EMAIL PROTECTED]> writes:
In py3k string%dictionary is going away.
>>> Why do you say that? It's not going away in Python 3.0.
>>
>> I also got the impression that it was going away. PEP 3101's abstract
>> says:
>>
>> This PEP proposes a new system for built-in stri
>>> In py3k string%dictionary is going away.
>> Why do you say that? It's not going away in Python 3.0.
>
> I also got the impression that it was going away. PEP 3101's abstract
> says:
>
> This PEP proposes a new system for built-in string formatting
> operations, intended as a replacem
Gabriel Genellina wrote:
>> Has the standard library changed that much? I thought was it mainly the
>> deletion of old seldom used modules that happens in new releases anyways.
>
> *and* renaming of old module names that don't follow PEP8, and merging
> others into packages for better structure.
"Martin v. Löwis" <[EMAIL PROTECTED]> writes:
>> In py3k string%dictionary is going away.
>
> Why do you say that? It's not going away in Python 3.0.
I also got the impression that it was going away. PEP 3101's abstract
says:
This PEP proposes a new system for built-in string formatting
> In py3k string%dictionary is going away.
Why do you say that? It's not going away in Python 3.0.
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
En Mon, 21 Apr 2008 16:42:41 -0300, Ross Ridge
<[EMAIL PROTECTED]> escribió:
Ideally, I can implement some form of cross-compatible code
so that I need maintain only a single code base, and I have managed to
do so on a number of fronts (with the help of Robert A. Clark):
Perhaps you can mana
Carl Banks <[EMAIL PROTECTED]> wrote:
> If you don't like Python 3, DON'T USE IT.
That's the plan.
Paul McGuire <[EMAIL PROTECTED]> wrote:
>I've read this position a number of times in this and related threads,
>and it overlooks one constituency of Python developers - those who
>develop and su
Gabriel Genellina wrote:
> You have plenty of time to evaluate alternatives. Your code may become
> obsolete even before 3.3 is shipped.
Sure, and don't forget to save two bytes when storing the year. ;)
Stefan
--
http://mail.python.org/mailman/listinfo/python-list
On Apr 19, 4:42 am, Carl Banks <[EMAIL PROTECTED]> wrote:
>
> If you don't like Python 3, DON'T USE IT.
>
I've read this position a number of times in this and related threads,
and it overlooks one constituency of Python developers - those who
develop and support modules for use by other Python us
En Fri, 18 Apr 2008 12:58:56 -0300, Aaron Watters <[EMAIL PROTECTED]> escribió:
> Why is the migration to py3k a concern?
> For example I have libraries which use string%dictionary
> substitution where the dictionary is actually an object
> which emulates a dictionary. The __getitem__ for
> the o
On Apr 18, 11:58 am, Aaron Watters <[EMAIL PROTECTED]> wrote:
> Why is the migration to py3k a concern?
> For example I have libraries which use string%dictionary
> substitution where the dictionary is actually an object
> which emulates a dictionary. The __getitem__ for
> the object can be very e
On Apr 18, 4:19 pm, Kay Schluehr <[EMAIL PROTECTED]> wrote:
> On 18 Apr., 23:09, Matimus <[EMAIL PROTECTED]> wrote:
>
> > The reason it doesn't work is that you are unpacking the dictionary
> > with **, and you have done nothing to define any keys or define a
> > length.
>
> This is a non-issue. Th
On Fri, 18 Apr 2008 16:19:38 -0700, Kay Schluehr wrote:
> On 18 Apr., 23:09, Matimus <[EMAIL PROTECTED]> wrote:
>> The reason it doesn't work is that you are unpacking the dictionary
>> with **, and you have done nothing to define any keys or define a
>> length.
>
> This is a non-issue. The class
On 18 Apr., 23:09, Matimus <[EMAIL PROTECTED]> wrote:
> The reason it doesn't work is that you are unpacking the dictionary
> with **, and you have done nothing to define any keys or define a
> length.
This is a non-issue. The class derives from dict; it has all the
desired attributes. It is also
On Apr 18, 8:58 am, Aaron Watters <[EMAIL PROTECTED]> wrote:
> Why is the migration to py3k a concern?
> For example I have libraries which use string%dictionary
> substitution where the dictionary is actually an object
> which emulates a dictionary. The __getitem__ for
> the object can be very ex
On 18 Apr., 20:07, Aaron Watters <[EMAIL PROTECTED]> wrote:
> I don't really know, but I think "fixing" the above issue for
> string.format(...) might involve changing the representation of
> every python stack frame... not worth it in this case if there
> is any penalty (afaik there isn't).
In P
> Try coming up with a real standard for evaluation.
> How much of a performance hit will actually cause you trouble? 1% extra
> on string interpolation? 10%? 50%? 200%?
You misread my comment. I don't want function calls to support
dictionary emulation if there is a speed penalty because this
On Fri, 2008-04-18 at 08:58 -0700, Aaron Watters wrote:
> Why is the migration to py3k a concern?
> For example I have libraries which use string%dictionary
> substitution where the dictionary is actually an object
> which emulates a dictionary. The __getitem__ for
> the object can be very expensi
Why is the migration to py3k a concern?
For example I have libraries which use string%dictionary
substitution where the dictionary is actually an object
which emulates a dictionary. The __getitem__ for
the object can be very expensive and is only called when
needed by the string substitution.
In
34 matches
Mail list logo
