On Thu, Nov 5, 2009 at 1:08 PM, Martin v. Löwis mar...@v.loewis.dewrote:
Mike Krell wrote:
Well, 3to2 would then be an option for you: use Python 3 as the
source
language.
Making life easier for 3to2 is an *excellent* rationale for backports.
Clarifying a bit of potentially
On Wed, Nov 4, 2009 at 12:02 PM, Martin v. Löwis mar...@v.loewis.dewrote:
The main reason I want a long 2.x series is that I believe it would more
easily allow us infrastructure folks to drop support for *older*
versions. With this big 2.x-3.x chasm, I can't really see an end in
sight
On Thu, Oct 22, 2009 at 1:24 PM, Martin v. Löwis mar...@v.loewis.dewrote:
Can you please explain why it would be desirable
to [backport nonlocal]? 2.7 will likely be the last 2.x release, so only a
fairly
small portion of the applications would be actually able to use this (or
any other new
Is there any possibility of backporting support for the nonlocal keyword
into a 2.x release? I see it's not in 2.6, but I don't know if that was an
intentional design choice or due to a lack of demand / round tuits. I'm
also not sure if this would fall under the scope of the proposed moratorium
On 3/15/07, Terry Reedy [EMAIL PROTECTED] wrote:
As to the usefulness of current behavior, the only supposed use-case code
posted, that I have noticed, was that it made it easy to turn '.emacs' into
'1.emacs', but then MK said the app does not really do that.
I said the name .emacs was used
On 3/16/07, Nick Coghlan [EMAIL PROTECTED] wrote:
splitext(name, ignore_leading_dot=False, all_ext=False)
+1. ISTM this is a reasonable way to go in the face of our existing
backward compatibility issue and the differing definitions of
extensions across OS's.
Mike
On 3/16/07, Martin v. Löwis [EMAIL PROTECTED] wrote:
If they pass the flag to the function, the code will stop running on
2.5 and earlier. This is worse than having code that works on all
versions. This is also whz I wondered how the flag helps backwards
compatibility: when people add the
On 3/16/07, Greg Ewing [EMAIL PROTECTED] wrote:
Mike Krell wrote:
I said the name .emacs was used as an example. For that matter, the
name a.txt was also used as an example. The use cases are real.
So does your application create any file names
that have a single dot at the beginning
On 3/15/07, Martin v. Löwis [EMAIL PROTECTED] wrote:
... the majority of the people polled thought that it ought to be fixed.
Personally, I didn't respond to your poll because I didn't think
this particular issue would come down to a silly head count of
self-selecting responders.
When I first
On 3/15/07, Martin v. Löwis [EMAIL PROTECTED] wrote:
Can you show us the relevant fragment of your code?
Sure:
for f in files:
try:
(root, ext) = os.path.splitext(f)
os.rename(f, '%s.%s%s' % (root, index, ext))
except OSError:
On 3/15/07, Martin v. Löwis [EMAIL PROTECTED] wrote:
Mike Krell schrieb:
Sure:
for f in files:
try:
(root, ext) = os.path.splitext(f)
os.rename(f, '%s.%s%s' % (root, index, ext))
except OSError:
die('renaming %s failed' % f
On 3/15/07, Mike Klaas [EMAIL PROTECTED] wrote:
Unacceptable? You code fails in (ISTM) the more common case of an
extensionless file.
I'm well aware of that limitation. However, what seems to you as a
more common case is, in the context of this particular application, a
case that never
On 3/15/07, Martin v. Löwis [EMAIL PROTECTED] wrote:
*don't* consider .emacs to be a file with an empty filename and
a .emacs extension. They also (alternatively) support a directory
called .emacs.d for startup files, and I would be equally surprised
if they registered .d as extension (about
I think this is Python's popularity. One factor is ready availability:
normal users don't build Python from source. So Windows users download
it from python.org, everybody else gets the binaries from the OS vendor.
Another factor is that the ActiveState ActivePython distribution for
Windows
Based on the behaviour of str and the fact that overriding unicode.__repr__
works just fine, I'd say file a bug on SF.
Done. This is item 1583863.
Mike
___
Python-Dev mailing list
Python-Dev@python.org
class S(str):
def __str__(self): return S.__str__
class U(unicode):
def __str__(self): return U.__str__
print str(S())
print str(U())
This script prints:
S.__str__
U.__str__
Yes, but print U() prints nothing, and the explicit str() should not
be necessary.
Mike
Is this a bug? If not, how do I override __str__ on a unicode derived class?
class S(str):
def __str__(self): return '__str__ overridden'
class U(unicode):
def __str__(self): return '__str__ overridden'
def __unicode__(self): return u'__unicode__ overridden'
s = S()
u = U()
print
What's wrong with nonlocal? I don't think i've seen an argument
against that one so far (from Talin or others).
It sounds a bit awkward to me. Also, it would be nice if the keyword
indicated which scope was operative.
If I've followed the discussions correctly, I think the parent scope
would
On 7/10/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
I don't think the keyword should indicate a scope.
I'd prefer it if LOAD_WHATEVER just percolated its way up the chain of
cells (or could be identified at compile time by inspecting the AST as I
think Guido intends) without the programmer
Greg Ewing greg.ewing at canterbury.ac.nz writes:
I've just been playing around with metaclasses, and
I think I've stumbled across a reason for having
class decorators as an alternative to metaclasses
for some purposes.
There has also been discussion on the IronPython mailing list that
20 matches
Mail list logo
