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 return
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 may not be
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 base
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. I
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,
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 java, for
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 accept
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.
--
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 your
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 Python
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 painful emotion
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
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.0
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 while
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 that
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 (with
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
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.
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 replacement [sic]
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 object
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 users.
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
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 support
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
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
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
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
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 expensive
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 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 Python
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
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 not
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 derives
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. The class
34 matches
Mail list logo
