Re: [Python-Dev] 2.7 Release? 2.7 == last of the 2.x line?
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 misleading editing: I wrote neither of the statements quoted above. M v L wrote the first and Nick C. wrote the second. I'm skeptical. If new features get added to 2.7: why would that simplify 3to2? It couldn't *use* these features, since it surely would have to support 2.6 and earlier as well. Not sure what 3to2 would do about difficult-to-convert 3.x feature (as, perhaps, the nonlocal keyword). If it currently gives up, it then may offer you to restrict your target versions to 2.7+. Not sure whether users would use that option, though - perhaps they rather stop using nonlocal in 3.x if 3to2 cannot support it for all 2.x versions they are interested in. Perhaps 3to2 has a work-around that still provides a good backport in most cases. Then, the backport would not make the tool any simpler: if 3to2 would start using the backport, it would actually get more complicated (not easier), as it now needs to support two cases. I basically agree with you here, except perhaps for the likely definition of versions they are interested in. You have suggested on several occasions that a 2.7 (or 2.8) containing new syntax such as nonlocal would be of limited value because the vast majority of developers interested in supporting 2.x would have to support 2.6 as well. I respectfully suggest that may not necessarily be the case. I suspect that there are lots of small fish out there like me who have the luxury of being able to hop onto whatever version of the language suits them the best. Not to mention all of the new users who will be drawn to Python over the next several years while the 3.x standard library and third party library situation becomes more stable and comprehensive. Why not make the 2.x feature set the best it can be given the likelihood that 2.x will be the most compelling alternative to many users until the 3.x libraries mature? Of course, it's easy for me to ask other people to the hard work. It might be fun to take a crack at implementing nonlocal myself, but I know next to nothing about the implementation of CPython. By the time I pestered y'all with enough questions to get up to speed, you'd probably wish you'd just implemented it yourself -- less work :-) Mike ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.7 Release? 2.7 == last of the 2.x line?
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 for Twisted using Python 2.x as its _source_ language, translating with 2to3. Well, 3to2 would then be an option for you: use Python 3 as the source language. A migration path which would be made all the more compelling with the addition of the nonlocal keyword to 2.7 ;-) Mike ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] nonlocal keyword in 2.x?
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 feature added to 2.7): most code supporting 2.x will also have to support 2.6, so the keyword won't be available to such code, anyway. Others have explained the rationale for the backport, so I won't bother repeating those arguments. I understand your point about code supporting 2.6, but as you say, that applies to any new features being added in 2.7. I'm therefore confused as to what the rationale for a 2.7 release is. It's a bump in minor release number, so it's purpose is to add new features, correct? Could someone please explain what new features are currently envisioned for 2.7? Why would those make the cut but a not backport of nonlocal? Mike ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] nonlocal keyword in 2.x?
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 new language features (although my first impression was that it could be allowed since it already exists in python 3. One of my motivations for asking is a recent blog post by Fernando Perez of IPython fame that describes an interesting decorator-based idiom inspired by Apple's Grand Central Dispatch which would allow many interesting possibilities for expressing parallelization and other manipulations of execution context for blocks of python code. Unfortunately, using the technique to its fullest extent requires the nonlocal keyword. The blog post is here: https://cirl.berkeley.edu/fperez/py4science/decorators.html Mike ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal to revert r54204 (splitext change)
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 as an example. For that matter, the name a.txt was also used as an example. The use cases are real. Mike ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal to revert r54204 (splitext change)
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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal to revert r54204 (splitext change)
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 flag, the code stops working on old versions, so it will *not* be backwards compatible. I don't understand. Under Nick's proposal, calling splitext with no keyword parameters results in the exact behavior we have today, so it's obviously backward compatible. If you use a keyword parameter, you're using a new feature implemented in 2.6, so there is no expectation of backward compatibility unless and until the keyword parameters are backported. Mike ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal to revert r54204 (splitext change)
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? Yes. How many more times would you like me to answer this question? Just in case you'd like me to answer it three more times, here are the answers: Yes, yes, and yes. Mike ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal to revert r54204 (splitext change)
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 needed to use splitext in my code, I tested the relevant corner case in question at the interactive prompt. I also read the docstring which explicitly documented the behavior. I then wrote my code accordingly. Knowing that this was well-defined and documented behavior and having followed this list during previous backward compatibility discussions, I knew that there was no way your proposed patch would make it into a minor release because many long-time active developers would rightfully point out that it gratuitously breaks code. In your radical departure from the common-sense approach to code-breaking changes that typically prevails here, you proved me wrong. So now I'm speaking up. FWIW, I agree completely with PJE's and glyph's remarks with respect to expectations of stability, especially in a minor release. Sorry, updating the NEWS file isn't good enough, because as has been amply demonstrated here, many people cannot be bothered to read the documentation. +1 on reverting the patch and not punishing those users who bothered to the documentation or test the corner cases themselves. Mike ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal to revert r54204 (splitext change)
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('renaming %s failed' % f)
Background:
This is a little utility that runs on windows that archives arbitrary
files. index is an integer.
For index == 1, I want a.txt to be renamed to a.1.txt, and I want
.emacs to be renamed to .1.emacs, thus preserving the extensions.
Under the new patch, the second file would be renamed to .emacs.1,
gratuitously breaking the extension preservation.
Mike
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal to revert r54204 (splitext change)
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)
Thanks! Looking more closely, it's not entirely clear where index
comes from - what if you already have a.1.txt. Will you set it
to 2? Will that then produce a.1.2.txt?
A bit more background: This runs periodically in a setting where the
files in the file list are regenerated in between invocations of this
code. Each time a renaming occurs, the index is incremented (it is
preserved in a file in between invocations). Thus, various
incarnations of a.txt would be archived as a.1.txt, a.2.txt,
etc. Similarly, copies of .emacs would be made as .1.emacs,
.2.emacs, etc. If b.1.txt appeared in the list of files to be
archived, it would be archived as b.1.1.txt, b.1.2.txt, etc.
Under the new patch, [.emacs] would be renamed to .emacs.1,
gratuitously breaking the extension preservation.
I can see that it breaks the behavior you intended it to have. However,
I disagree that it broke extension preservation. Rather, it *provides*
extension preservation, something that the old code did not do.
Here is a point of confusion. Bear in mind I'm running this under
windows, so explorer happily reports that .emacs has a type of
emacs. (In windows, file types are registered in the system based
on the extension -- all the characters following the last dot. An
unregistered extension is listed as its own type. Thus files ending
in .txt are listed as type Text Document, but files ending in
.emacs are listed as type emacs because it's an unregistered
extension.)
I often sort files in the explorer based on type, and I want a file
and all its backups to appear next to each other in such a sorted
list. That's exactly why I rename the files the way I do.
Thus, .1.emacs is what I want, and .emacs.1 is a markedly inferior
and unacceptable alternative. That's what I'm referring to by
extension preservation.
I also like to point out that the primary objective of the code
(archive arbitrary files) is still preserved - it still does that,
but in different manner. (disclaimer: I don't fully understand the
index part)
See above.
BTW, I want to echo Brett Cannon's comments about the tone. I've been
a bit testy about this breakage, however, upon reflection, it's clear
that it's not Martin's fault, but rather a shortcoming of the process.
Sorry, Martin. If you or anyone else was offended, please accept my
apologies.
Mike
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal to revert r54204 (splitext change)
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 occurs. I wrote the code with my particular use cases in mind. Mike ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal to revert r54204 (splitext change)
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 the only extension Emacs might register is .el/.elc). Agreed on both counts. I'm sure neither of these are registered extensions, but for what I care about the operative question is what windows explorer does with (what it considers to be) unregistered extensions. The reason the file is called .emacs on Windows is *not* because it should have that extension, but because it is called .emacs on Unix, and it is called that way because the Unix shell and ls suppress dotfiles unless explicitly asked to display them. Yes. Ok, I see why that would break. What do you do with files that really have no extension whatsoever (i.e. no dot at all)? That use case doesn't come up for this application -- see my response to Mike Klass. I actually muddied the waters here by using .emacs as an example. In practice, this app would never copy a .emacs file since its used to copy files used by itself. Mike ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] MSI being downloaded 10x more than all other files?!
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 isn't available for 2.5 yet. Early adopters have even fewer places to go than normal. Mike ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] __str__ bug?
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/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] __str__ bug?
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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] __str__ bug?
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 's:', s print str(s):, str(s) print 's substitued is %s\n' % s print 'u:', u print str(u):, str(u) print 'u substitued is %s' % u - s: __str__ overridden str(s): __str__ overridden s substitued is __str__ overridden u: str(u): __str__ overridden u substitued is Results are identical for 2.4.2 and 2.5c2 (running under windows). Mike ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Explicit Lexical Scoping (pre-PEP?)
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 be operative, so I humbly suggest parent. Mike ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Explicit Lexical Scoping (pre-PEP?)
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 having to name the binding scope. I agree completely. I realize that probably wasn't clear when I said it would be nice if the keyword indicated which scope was operative. I was really only trying to proffer a keyword which would hopefully suggest to a newbie that they should percolate up the chain of scopes. In this sense, the word outer works for me, but I'm sympathetic to Andrew Koenig's argument that outer is confusing because the innermost binding is actually affected. Since it might not just be in the immediate parent scope, how about ancestor? 0.5 wink That thought had occurred to me, but then I beat it down with a stick :-) My rationale was that the affected binding is the one seen by the parent, even if the parent did not create the binding itself. Greg Ewing's point about parent being a common variable name is well-taken, though. Mike ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Class decorators
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 class decorators would be a very useful syntax for expressing .NET attributes. http://lists.ironpython.com/pipermail/users-ironpython.com/2006-March/002007.html Mike ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
