On Thu, Nov 5, 2009 at 1:08 PM, "Martin v. Löwis" wrote:
> > 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
On Wed, Nov 4, 2009 at 12:02 PM, "Martin v. Löwis" wrote:
> > 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 for Twist
On Thu, Oct 22, 2009 at 1:24 PM, "Martin v. Löwis" wrote:
> 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 feature adde
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/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
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
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/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
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 (
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 oc
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' % (r
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:
die('ren
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
> 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
Window
> 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.
> 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
http://mail.python.org/mailman/listinfo/pyt
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 '
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_ 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 ha
> 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
wo
Greg Ewing 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 class
decor
20 matches
Mail list logo
