Re: [Python-Dev] [Python-3000] Warning for 2.6 and greater
Georg Brandl schrieb: >> If Python 3.0 was simply a release which removed deprecated features, >> there would clearly be no issue. I would update my code in advance of >> the 3.0 release to not use any of those features being removed, and >> I'm all set. But that's not what I'm hearing. Python 3 is both adding >> new ways to do things, and removing the older way, in the same >> version, with no overlap. This makes me very anxious. > > It has always been planned that in those cases that allow it, the new way to > do > it will be introduced in a 2.x release too, and the old way removed only in > 3.x. What does that mean for the example James gave: if dict.items is going to be an iterator in 3.0, what 2.x version can make it return an iterator, when it currently returns a list? There simply can't be a 2.x version that *introduces* the new way, as it is not merely a new API, but a changed API. Regards, Martin ___ Python-Dev mailing list [email protected] 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-3000] Warning for 2.6 and greater
On Friday 12 January 2007 19:19, Martin v. Löwis wrote: > Georg Brandl schrieb: > > It has always been planned that in those cases that allow it, > > the new way to do it will be introduced in a 2.x release too, > > and the old way removed only in 3.x. > > What does that mean for the example James gave: if dict.items is > going to be an iterator in 3.0, what 2.x version can make it > return an iterator, when it currently returns a list? > > There simply can't be a 2.x version that *introduces* the new > way, as it is not merely a new API, but a changed API. There's a couple of ways I see it - we could add a "-3" command line flag to enable 3.x compat, or maybe a from __future__ statement. Although the latter would be a global thing, which is different to how all existing from __future__s work, so probably not good. I don't see a path forward that doesn't involve something painful, so long as 3.0 is going to be the clean break. As I mentioned, though, I'd like as far as possible to make it so that 2.6 (with a flag) can be at least vaguely compatible with 3.0. Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list [email protected] 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-3000] Warning for 2.6 and greater
Georg Brandl <[EMAIL PROTECTED]> writes: > Armin Rigo schrieb: >> Hi Paul, >> >> On Wed, Jan 10, 2007 at 11:10:10PM +, Paul Moore wrote: >>> How many other projects/packages anticipate *not* migrating to Py3K, I >>> wonder? >> >> FWIW: Psyco. > > What will PyPy do? It will certainly support compiling Py3k code at some > point, > but will the codebase itself be converted? For practical reasons (we have enough work to be getting on with) PyPy is more-or-less ignoring Python 2.5 at the moment. After funding and so on, when there's less pressure, maybe it will seem worth it. Not soon though. Cheers, mwh -- I'm okay with intellegent buildings, I'm okay with non-sentient buildings. I have serious reservations about stupid buildings. -- Dan Sheppard, ucam.chat (from Owen Dunn's summary of the year) ___ Python-Dev mailing list [email protected] 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-3000] Warning for 2.6 and greater
On 11 Jan, 08:22 pm, [EMAIL PROTECTED] wrote: >On 1/11/07, James Y Knight <[EMAIL PROTECTED]> wrote: >> If the goal is really to have Py 3.0 be released later this year, >There will certainly be demand for an asynchronous server in 3.0, To flip the question around: there might be a demand for Twisted in 3.0, but will there be a demand for 3.0 in Twisted? It might just be easier for everyone concerned to just continue maintaining 2.x forever. I have yet to see a reason why, other than continued maintenance, 3.0 would be a preferable development platform. >So the two projects will operate independently, and the 3.0 one may be >smaller and less ambitious than Twisted. But if the need is there it >will be written. It is quite likely that someone else will write some completely different code for python 3.0 that calls select(). I hadn't considered that the goal of 3.0 was to *discover* these people by alienating existing Python developers - that's crafty! If so, though, you'll have to figure out a way to stop Anthony from providing all this compatibility stuff. He might make it too attractive for us to continue development on future versions :). >How did Perl 4 and Perl 5 handle the situation? I basically waited >2-3 years after Perl 5 came out, then started programming the new way. > If it mattered (it didn't), I would have tied my applications >specifically to Perl 4. I handled the Perl 4 to 5 transition by dropping Perl and moving to Python, because if I was going to port all my code to another language I wanted to at least port to a better language. ___ Python-Dev mailing list [email protected] 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-3000] Warning for 2.6 and greater
On 01:12 am, [EMAIL PROTECTED] wrote: >On Friday 12 January 2007 06:09, James Y Knight wrote: >> On Jan 10, 2007, at 6:46 PM, Benji York wrote: >> > Paul Moore wrote: >> >> How many other projects/packages anticipate *not* migrating to >> >> Py3K, I wonder? >> > >> > I certainly can't speak for the project as a whole, but I >> > anticipate a fair bit of work to port Zope 3 (100+ KLOC) to >> > Python 3.0. >> >> I (another Twisted developer, among other hats I wear) am also >> very worried about the Python 3.0 transition. > >I'm plan to try and make the transition as painless as possible. A >goal I have is to try and make it possible to write code that works >in both 2.6 and 3.0. Obviously 2.6 will be backwards-compatible >with previous versions, but I'd like to see it get either a command >line option or a from __future__ statement to enable compatibility >with 3.0-isms, like the dict.items change. This is all very encouraging. Please stick with a __future__ statement if at all possible though. The biggest challenge in migration is to reduce the impact so that it can be done partially in a real system. If you have a module X wants to be "3.0 safe" which imports a module Y from a different developer that is not, command line options for compatibility might not help at all. A __future__ statment in X but not in Y, though, would allow for a smooth transition. I can see how that would be tricky for things like dictionary methods, but it does seem doable. For example, have a has_key descriptor which can raise an AttributeError if the globals() of the calling stack frame has been marked in some way. >> Basically: my plea is: please don't remove the old way of doing >> things in Py 3.0 at the same time as you add the new way of doing >> things. > >If there was a way to make 2.6 as compatible as possible with 3.0, >would this make life less painful? Obviously there'd have to be >breakages in a backwards direction, but I'd hope it would make it >easier to go forward. Some things should also be OK to backport to >2.6 - for instance, I can't see an obvious reason why 2.6 can't >support "except FooError as oopsie" as an alternate spelling of >"except FooError, oopsie". You happen to have hit my favorite hot-button 3.0 issue right there :). I don't care about backticks but sometimes I _do_ have to catch exceptions. >Similarly, where the stdlib has been shuffled around, there should >be shims in 2.6 that allow people to work with the new names. This part I wouldn't even mind having to write myself. It would certainly be good to have somewhere more official though. >I don't think waiting for 2.7 to make the compatibility work is a >workable approach - we're something like 2.5-3 years away from a >2.7 release, and (optimistically) 12-18 months from a 3.0 final. >That leaves a window of 1.5-2 years where we are missing an >important tool for people. It would be nice if the versioning would actually happen in order. >> [1] Unless of course there's a perfect automated conversion >> script that can generate the 3.X compatible source code from the >> 2.X compatible source code. > >I doubt that the 2to3 script will be perfect, but hopefully it can >get most things. I can't see it easily fixing up things like > >check = mydict.has_key >... >if check(foo): Currently a common idiom, by the way, used throughout the lower levels of Twisted. >This is why I also want to add Py3kDeprecationWarning to 2.6. > >On that note, I'd like to see changes like the mass-change to the >stdlib in the 3.0 branch that changed raise A, B into raise A(B) >applied to the trunk. This makes it much easier to apply patches to >both the 3.0 branch and the trunk. Similar changes should be >applied to remove, for instance, use of <> and dict.has_key from >the stdlib. Simply put, I'd like the stdlib between 2 and 3 to be >as similar as possible. It would be nice if the stdlib could be used as a case study - if the 3 stdlib tests can pass on some version of 2 (or vice versa) that should be a minimum bar for application portability. Maybe a better way to handle the similarity is that the reorganized stdlib should simply be available as a separate piece of code on 2.x? That would allow 2.x to use any new features added and distinguish between code which had been moved to use new stdlib APIs and that which hadn't. ___ Python-Dev mailing list [email protected] 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-3000] Warning for 2.6 and greater
On 07:56 am, [EMAIL PROTECTED] wrote: >Additionally, without a 2.x<->3.x upgrade path 3.x is essentially a >new language, having to build a new userbase from scratch. Worse >yet, 2.x will suffer as people have the perception "Python 2? >That's a dead/abandoned language" It's worse than that. This perception has _already_ been created. I already have heard a few folks looking for new languages to learn choose Ruby over Python and give Py3K as a reason. "Isn't Python going to be totally different in a few years anyway? I'll just wait until then, seems like a waste of time to learn it now." Given Ruby's own checkered history of compatibility, I don't think this is an _accurate_ perception, but it is the nature of perception to be inaccurate. If the plan is to provide a smooth transition, it would help a lot to have this plan of foward and backward compatibility documented somewhere very public. It's hard to find information on Py3K right now, even if you know your way around the universe of PEPs. FWIW, I also agree with James that Python 3 shouldn't even be released until the 2.x series has reached parity with its feature set. However, if there's continuity in the version numbers instead of the release dates, I can at least explain to Twisted users that we will _pretend_ they are released in the order of their versions. ___ Python-Dev mailing list [email protected] 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-3000] Warning for 2.6 and greater
On 10:12 am, [EMAIL PROTECTED] wrote: >For practical reasons (we have enough work to be getting on with) PyPy >is more-or-less ignoring Python 2.5 at the moment. After funding and >so on, when there's less pressure, maybe it will seem worth it. Not >soon though. I think I know what you mean from previous conversations, but the context of the question makes the answer ambiguous. Are you ignoring 2.5 in favor of 2.4, or 3.0? ___ Python-Dev mailing list [email protected] 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-3000] Warning for 2.6 and greater
On Friday 12 January 2007 21:42, [EMAIL PROTECTED] wrote: > If the plan is to provide a smooth transition, it would help a > lot to have this plan of foward and backward compatibility > documented somewhere very public. It's hard to find information > on Py3K right now, even if you know your way around the universe > of PEPs. I'd like to see this happen, too - however, there's no way I can even think about it until after LCA next week. First of all, of course, we need to get agreement on the preferred way forward. > FWIW, I also agree with James that Python 3 shouldn't even be > released until the 2.x series has reached parity with its feature > set. However, if there's continuity in the version numbers > instead of the release dates, I can at least explain to Twisted > users that we will _pretend_ they are released in the order of > their versions. I'm not sure what "parity with it's feature set" means. I think there's going to be some 3.0isms that just cannot be done sanely in 2.x - for instance, the new I/O subsystem. But I do hope that it's _possible_ to work in a version of the language that works in both 2.6+ and 3.0+, even if under the hood there are differences. For instance, if we did "except foo as bar" for 2.6, it might not auto-clean-up the exception object when it drops out of the except: block. I put up www.python.org/sf/1633807 a short time ago that deals with one of the big concerns I had - print vs print() (it was also as a learning exercise to figure out if it was possible, and how it might work). Something similar could probably be done for exec(). I suspect the problem cases are going to be things like the dictionary code - your idea (in another email) of trying to look up globals would probably cause a horrible performance issue, but it may be possible to do _something_ clever. Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list [email protected] 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-3000] Warning for 2.6 and greater
On 11:22 am, [EMAIL PROTECTED] wrote: >> FWIW, I also agree with James that Python 3 shouldn't even be >> released until the 2.x series has reached parity with its feature >> set. However, if there's continuity in the version numbers >> instead of the release dates, I can at least explain to Twisted >> users that we will _pretend_ they are released in the order of >> their versions. > >I'm not sure what "parity with it's feature set" means. I don't either! "Parity with it is feature set"? I can't even parse that! ;-) By "parity with *its* feature set", though, I meant what you said here: >I do hope that it's _possible_ to work in a version of the language that works >in both 2.6+ and 3.0+, even if under the hood there are differences. In order to do this, everything that has been changed in 3.0 has to have some mechanism for working both ways in some 2.x release. I phrased this as its "feature set" because I am not aware of any new functionality in 3.0 that simply isn't available 2.x - everything I've seen are "cleanups", which expose basically the same features as 2.5. If there are some real new features, then I am in error. ___ Python-Dev mailing list [email protected] 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-3000] Warning for 2.6 and greater
Martin v. Löwis schrieb: > Georg Brandl schrieb: >>> If Python 3.0 was simply a release which removed deprecated features, >>> there would clearly be no issue. I would update my code in advance of >>> the 3.0 release to not use any of those features being removed, and >>> I'm all set. But that's not what I'm hearing. Python 3 is both adding >>> new ways to do things, and removing the older way, in the same >>> version, with no overlap. This makes me very anxious. >> >> It has always been planned that in those cases that allow it, the new way to >> do >> it will be introduced in a 2.x release too, and the old way removed only in >> 3.x. > > What does that mean for the example James gave: if dict.items is going > to be an iterator in 3.0, what 2.x version can make it return an > iterator, when it currently returns a list? > > There simply can't be a 2.x version that *introduces* the new way, as it > is not merely a new API, but a changed API. Well, that is one of the cases in which that won't be possible ;) But e.g. moved methods, libraries or new syntax are areas where changes can be introduced in 2.x (in case of new syntax with a __future__ statement, of course). Georg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] trunk changes not suited for 3.0
Hi, currently, changes in the trunk are merged to the p3yk branch. What about changes such as the discussed -3 warn option, or __future__ imports for stuff that'll be in 3k anyway? Can/should these revisions just be excluded from the merge? Or would it be better to apply them to a new branch? Georg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] trunk changes not suited for 3.0
AFAIK Thomas just excludes these from the merge, or occasionally (if they make it through) they will be eradicated in the p3yk branch, and then they'll be excluded from future merges of related changes (since those would be flagged as conflict). On 1/12/07, Georg Brandl <[EMAIL PROTECTED]> wrote: > Hi, > > currently, changes in the trunk are merged to the p3yk branch. > What about changes such as the discussed -3 warn option, or __future__ > imports for stuff that'll be in 3k anyway? > > Can/should these revisions just be excluded from the merge? Or would > it be better to apply them to a new branch? > > Georg > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] 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-3000] Warning for 2.6 and greater
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jan 12, 2007, at 9:17 AM, Georg Brandl wrote: > Well, that is one of the cases in which that won't be possible ;) I think there will be at least three areas that will make porting a challenge: - - APIs where the semantics have changed instead of being moved, renamed, or extended - - C API changes for extensions and embedded apps - - Unicode/str/bytes incompatibilities It's worth spending time thinking about how we can help ease the transition for each. There may be more thing too. I wonder if it doesn't make sense for all 3xxx PEPs to include a discussion section on porting. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRael9nEjvBPtnXfVAQIqRQP+PrYnz/XSnGsplGj1+/MtBFzkbKeZEEn7 tN1NyKNZ7Rt7w+K9JhO9D1XismB3Wwwd66d7+N8vY/y/ea/cMosUwYS7LbwTmvcV MX3HeeqSfzjseuaTE2/3Mj+HHTWCE6dWASG5CHOguqs84FPeA5b+tbNNcp0Prp6I HnkfO6d2V/I= =TphK -END PGP SIGNATURE- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] trunk changes not suited for 3.0
On 1/12/07, Guido van Rossum <[EMAIL PROTECTED]> wrote: AFAIK Thomas just excludes these from the merge, Indeed I would. or occasionally (if they make it through) they will be eradicated in the p3yk branch, and then they'll be excluded from future merges of related changes (since those would be flagged as conflict). On 1/12/07, Georg Brandl <[EMAIL PROTECTED]> wrote: > Hi, > > currently, changes in the trunk are merged to the p3yk branch. > What about changes such as the discussed -3 warn option, or __future__ > imports for stuff that'll be in 3k anyway? > > Can/should these revisions just be excluded from the merge? Or would > it be better to apply them to a new branch? > > Georg > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/thomas%40python.org -- Thomas Wouters <[EMAIL PROTECTED]> Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Code working in both 2.x and 3.X
Ron Adam wrote: > I thinking that the 3.0.X version be considered a try it out (alpha) release > to > generate plenty of feed back, and the 3.1.X version be the first version > meant > for actual development use. +1 for this approach. I think it's very clear, and everybody will understand it (ok, not everybody, we know people...). -- . Facundo . Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] The bytes type (was Re: Warning for 2.6 and greater)
On Fri, Jan 12, 2007 at 10:14:57AM -0500, Barry Warsaw wrote: > I think there will be at least three areas that will make porting a > challenge: ... > - - Unicode/str/bytes incompatibilities Something I've been meaning to bring up... do we know what shape the Unicode/str/bytes resolution will take? It would be nice to know so that similar changes can be made to Jython. For example, str in Jython is a Unicode type, but things like the MD5 module should really only be dealing with 8-bit strings. Is PEP 358 still the current thinking on the bytes type? If yes, should we set about implementing it for Jython and Python 2.6? --amk ___ Python-Dev mailing list [email protected] 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-3000] Warning for 2.6 and greater
At 11:59 AM 1/12/2007 +, [EMAIL PROTECTED] wrote: >In order to do this, everything that has been changed in 3.0 has to have >some mechanism for working both ways in some 2.x release. I phrased this >as its "feature set" because I am not aware of any new functionality in >3.0 that simply isn't available 2.x - everything I've seen are "cleanups", >which expose basically the same features as 2.5. > >If there are some real new features, then I am in error. If I understand correctly, argument annotations, and exceptions having traceback attributes are new features. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] file(file)
Forwarded for discussion from http://www.python.org/sf/1633665.
--amk
[forwarded from http://bugs.debian.org/327060]
Many types in Python are idempotent, so that int(1) works
as expected, float(2.34)==2.34, ''.join('hello')=='hello'
et cetera.
Why not file()? Currently, file(open(something, 'r')) fails
with "TypeError: coercing to Unicode: need string or buffer, file found."
Semantically, file(fd) should be equivalent to os.fdopen(fd.fileno())
or the proposed file.fromfd() (Jp Calderone, Python-dev, 2003).
You should get another independent
file object that accesses the same file.
What would be gained?
Primarily, it would allow you to derive classes from file more easily.
At present, if you want to derive like so, you're class can only work
when passed a file name or buffer.
class file_with_caching(file):
def __init__(self, something):
file.__init__(self, something)
def etcetera...
For instance, you have no way of creating a file_with_caching()
object from the file descriptors returned from os.fork().
Also, you have no way of taking a file that is already open,
and creating a file_with_caching() object from it. So,
you can't use classes derived from file() on the standard input
or standard output.
This breaks the nice Linux OS-level definition of a file descriptor.
At the Linux level, you have a nice uniform interface where all
file descriptors are equally good. At the python level, some
are better than others. It's a case where Python unnecessarily
restricts what you can do.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Code working in both 2.x and 3.X
On 1/12/07, Facundo Batista <[EMAIL PROTECTED]> wrote: > Ron Adam wrote: > > > I thinking that the 3.0.X version be considered a try it out (alpha) > > release to > > generate plenty of feed back, and the 3.1.X version be the first version > > meant > > for actual development use. > > +1 for this approach. > > I think it's very clear, and everybody will understand it (ok, not > everybody, we know people...). To the contrary, I think this is just a game with semantics -- if we tell people not to use 3.0 because it is still alpha quality then we won't get *actual* feedback until we release 3.1, and we'd still have to do a 3.2 which takes the feedback from serious users into account. IMO we should strive for 3.0 to be the best release we can make it -- on a par with 2.4.0, 2.5.0 and 2.6.0. I want about a year between 3.0a1 (to be released in the first half of this year) and 3.0final. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The bytes type (was Re: Warning for 2.6 and greater)
On 1/12/07, A.M. Kuchling <[EMAIL PROTECTED]> wrote: > On Fri, Jan 12, 2007 at 10:14:57AM -0500, Barry Warsaw wrote: > > I think there will be at least three areas that will make porting a > > challenge: >... > > - - Unicode/str/bytes incompatibilities > > Something I've been meaning to bring up... do we know what shape the > Unicode/str/bytes resolution will take? It would be nice to know so > that similar changes can be made to Jython. For example, str in > Jython is a Unicode type, but things like the MD5 module should really > only be dealing with 8-bit strings. This hasn't been sorted out in much detail, alas. I expect we'll have some tough decisions to make about which APIs use bytes and which use str. (For another example, considere base64.) > Is PEP 358 still the current thinking on the bytes type? If yes, > should we set about implementing it for Jython and Python 2.6? I'm afraid that PEP is not up to date; I don't think I used it as a reference when I coded up the current bytes type in Py3k. Whenever the PEP matches the implementation, we can be confident that we have the right design. Where they differ, I'd be inclined to believe the code, unless it's a matter of an as-yet-unimplemented feature, or a temporary measure while we still have the 8-bit str type. Some examples of differences: - bytes(100) returns a bytes array of length 100 filled with zeros. - repr() of a bytes array uses hex notation instead of decimal. - .fromhex() and .hex() are not implemented. - .append(), .insert(), .remove(), .pop(), .extend(), .index(), .count() are not implemented. - bytes has .decode() and .join() methods that are not in the PEP. In general I believe the actual bytes object resembles strings more than lists, and probably will grow more string-like behavior instead of more list methods. (Case in point: 'in' implements a substring check like strings do.) -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] file(file)
On 1/12/07, A.M. Kuchling <[EMAIL PROTECTED]> wrote:
> Forwarded for discussion from http://www.python.org/sf/1633665.
>
> --amk
>
> [forwarded from http://bugs.debian.org/327060]
>
> Many types in Python are idempotent, so that int(1) works
> as expected, float(2.34)==2.34, ''.join('hello')=='hello'
> et cetera.
The join(0 example seems out of place, since it is not a constructor call.
> Why not file()? Currently, file(open(something, 'r')) fails
> with "TypeError: coercing to Unicode: need string or buffer, file found."
>
> Semantically, file(fd) should be equivalent to os.fdopen(fd.fileno())
> or the proposed file.fromfd() (Jp Calderone, Python-dev, 2003).
> You should get another independent
> file object that accesses the same file.
That's rather Unix-centric semantics. I don't think the same thing
exists on Windows.
We should also consider the semantics in more detail. Should the seek
position be shared between the two objects? What about buffering?
I'm not sure I understand the use case; I don't believe I've ever felt
the need for this.
> What would be gained?
>
> Primarily, it would allow you to derive classes from file more easily.
Inheritance is overrated.
> At present, if you want to derive like so, you're class can only work
> when passed a file name or buffer.
>
> class file_with_caching(file):
> def __init__(self, something):
> file.__init__(self, something)
>
> def etcetera...
But the devil is in the details. What are the "caching" semantics you
want to implement here? Is it appropriate to subclass file for that
purpose, or is it better to use a wrapper (or proxy or delegate)?
> For instance, you have no way of creating a file_with_caching()
> object from the file descriptors returned from os.fork().
I didn't know fork() returned a file descriptor.
> Also, you have no way of taking a file that is already open,
> and creating a file_with_caching() object from it. So,
> you can't use classes derived from file() on the standard input
> or standard output.
More hints that you shouldn't be using inheritance.
> This breaks the nice Linux OS-level definition of a file descriptor.
But a Python file is not a Unix file descriptor. It's more like a C stdio file.
> At the Linux level, you have a nice uniform interface where all
> file descriptors are equally good. At the python level, some
> are better than others. It's a case where Python unnecessarily
> restricts what you can do.
That's what you say. I see a lot of murky thinking.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The bytes type
On Fri, Jan 12, 2007 at 09:51:25AM -0800, Guido van Rossum wrote: > I'm afraid that PEP is not up to date; I don't think I used it as a > reference when I coded up the current bytes type in Py3k. Whenever the > PEP matches the implementation, we can be confident that we have the > right design. Where they differ, I'd be inclined to believe the code, > unless it's a matter of an as-yet-unimplemented feature, or a > temporary measure while we still have the 8-bit str type. Is the Py3k bytes type considered 'finished', then, or at least 'largely correct', or is it still experimental? I could backport the type to the 2.x branch; it could be a new feature in 2.6 and then be added to Jython. 2.6 wouldn't go changing existing APIs to begin requiring or returning the bytes type[*], of course, but extensions and new modules might use it. --amk [*] Anyone else keep wanting to write "byte type"? ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The bytes type
[A.M. Kuchling] > 2.6 wouldn't go changing existing APIs to begin requiring or returning > the bytes type[*], of course, but extensions and new modules might use > it. The premise is dubious. If I am currently maintaining a module, why would I switch to a bytes type and forgo compatibility with Py2.5 and prior? I might as well just convert it to run on Py3.0 and leave my Py2.5 code as-is for people who want to run 2.x. If I'm writing a new module, what's the point of twisting myself into knots to get it to run on both Py2.6 and Py3.0? That just makes coding harder (by limiting me to the intersection of the feature sets). I think we should draw a line in the sand and resolve not to garbage-up Py2.6. The whole Py3.0 project is about eliminating cruft and being free of the bonds of backwards compatibility. Adding non-essential cruft to Py2.6 goes against that philosophy. Raymond ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The bytes type
On 1/12/07, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > [A.M. Kuchling] > > 2.6 wouldn't go changing existing APIs to begin requiring or returning > > the bytes type[*], of course, but extensions and new modules might use > > it. > > The premise is dubious. > > If I am currently maintaining a module, why would I switch to a bytes type > and forgo compatibility with Py2.5 and prior? I might as well just convert > it to run on Py3.0 and leave my Py2.5 code as-is for people who want to > run 2.x. > > If I'm writing a new module, what's the point of twisting myself into knots > to get it to run on both Py2.6 and Py3.0? That just makes coding harder > (by limiting me to the intersection of the feature sets). > > I think we should draw a line in the sand and resolve not to garbage-up Py2.6. > The whole Py3.0 project is about eliminating cruft and being free of the > bonds of backwards compatibility. Adding non-essential cruft to Py2.6 > goes against that philosophy. I'm not so sure, since 2.6 will likely be out and stable long before 3.0 gains much of a foothold. I believe the experiences with a similar approach in the Zope world for the 2->3 transition was overall a favorable one. However, I'd be loathe to make any compromises in 3.0 in order to make life easier for 2.6. The burden must be on 2.6 (and 2.7-2.9), and if it's just impossible, that's too bad for them. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The bytes type
On Fri, Jan 12, 2007 at 10:49:13AM -0800, Raymond Hettinger wrote: > I think we should draw a line in the sand and resolve not to garbage-up > Py2.6. > The whole Py3.0 project is about eliminating cruft and being free of the > bonds of backwards compatibility. Adding non-essential cruft to Py2.6 > goes against that philosophy. We could add the bytes type to Jython only and leave it out of the 2.x series. That still requires nailing down the semantics of 'bytes'. --amk ___ Python-Dev mailing list [email protected] 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-3000] Warning for 2.6 and greater
On 1/12/07, Barry Warsaw <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Jan 12, 2007, at 9:17 AM, Georg Brandl wrote: > > > Well, that is one of the cases in which that won't be possible ;) > > I think there will be at least three areas that will make porting a > challenge: > > - - APIs where the semantics have changed instead of being moved, > renamed, or extended > - - C API changes for extensions and embedded apps > - - Unicode/str/bytes incompatibilities > > It's worth spending time thinking about how we can help ease the > transition for each. There may be more thing too. I wonder if it > doesn't make sense for all 3xxx PEPs to include a discussion section > on porting. Yeah, when this was talked about last time, I wrote PEP 3002 which requests exactly this: http://www.python.org/dev/peps/pep-3002/ It basically proposes that all backwards-incompatible changes be discussed in a PEP somewhere, and that code like Anthony's be added to 2.X to ease the transition. Originally, it has proposed just a utility like Guido's 2to3 but Guido himself suggested something like Anthony's approach: http://mail.python.org/pipermail/python-3000/2006-April/001444.html I'm planning to update the PEP with any new conclusions arrived at in this thread. Steve -- I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a tiny blip on the distant coast of sanity. --- Bucky Katt, Get Fuzzy ___ Python-Dev mailing list [email protected] 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-3000] Warning for 2.6 and greater
On 1/12/07, Steven Bethard <[EMAIL PROTECTED]> wrote: > Yeah, when this was talked about last time, I wrote PEP 3002 which > requests exactly this: > > http://www.python.org/dev/peps/pep-3002/ > > It basically proposes that all backwards-incompatible changes be > discussed in a PEP somewhere, and that code like Anthony's be added to > 2.X to ease the transition. Originally, it has proposed just a > utility like Guido's 2to3 but Guido himself suggested something like > Anthony's approach: > > http://mail.python.org/pipermail/python-3000/2006-April/001444.html To complement 2to3, not to replace it. > I'm planning to update the PEP with any new conclusions arrived at in > this thread. I think that now the 2to3 tool is a reality, its limitations should perhaps be taken into account. For example, I don't believe it is realistic to expect it to do semantic analysis, which means that for example it can't be expected to know whether 'd' in 'd.keys()' is a dict or something else. Also, in 'k = d.keys()' it can't be expected to analyze how k is used later on; to be safe, it will translate all occurrences of d.keys() into list(d.keys()) which is known to work (and won't be slower than the original code either). -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Proposed 3.0 compatiblity module
ISTM, we can decide to limit 3.0's impact to a single compatibility module, essentially as an alternate set of builtins. import __new_builtins__ for name in 'bytes dict coerce'.split(): # list any new features you want to support setattr(__builtins__, name, getattr(__new_builtins__, name)) The bytes type would just be the new type. The dict would have keys=iterkeys, no has_key, etc. The coerce function would work but have a DeprecationWarning or somesuch. If you want future division, we already have a mechanism for that. If you want to eliminate backticks, just grep for them. If you don't care about 3.0 compatibilty, just don't import the module. Outside of a compatibility module, we can decide to leave Py2.6 unmolested by Py3.0, so I can stop being cranky. Raymond ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The bytes type
On 06:49 pm, [EMAIL PROTECTED] wrote: >I think we should draw a line in the sand and resolve not to garbage-up Py2.6. >The whole Py3.0 project is about eliminating cruft and being free of the >bonds of backwards compatibility. Adding non-essential cruft to Py2.6 >goes against that philosophy. Emotionally charged like "cruft" and "garbage" are obscuring the issue. Let's replace them with equivalents charged in the opposite direction: "I think we should draw a line in the sand and resolve not to compatibility-up Py2.6. The whole Py3.0 project is about eliminating useful libraries and being free of the bonds of working software. Adding non-essential forward-compatibility to Py2.6 goes against that philosophy." The benefit (to me, and to many others) of 3.x over 2.x is the promise of more future maintenance, not the lack of cruft. In fact, if I made a list of my current top ten problems with Python, "cruft" wouldn't even make it in. There is lots of useful software that will not work in the 3.0 series, and without forward compatibility there is no way to get there from here. As Guido said, if 3.0 is going to break compatibility, that burdens the 2.x series with the need to provide transitional functionality. The upgrade path needs to be available in one version or the other, or 2.x needs to be maintained forever. You can't have it both ways. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The bytes type
On 1/12/07, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > [A.M. Kuchling] > > 2.6 wouldn't go changing existing APIs to begin requiring or returning > > the bytes type[*], of course, but extensions and new modules might use > > it. > > The premise is dubious. > > If I am currently maintaining a module, why would I switch to a bytes type > and forgo compatibility with Py2.5 and prior? I might as well just convert > it to run on Py3.0 and leave my Py2.5 code as-is for people who want to > run 2.x. A mutables bytes type is a useful addition to 2.X aside of the 3.0-compatibility motivation. Isn't that sufficient justification? -Mike ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The bytes type
glyph> "I think we should draw a line in the sand and resolve not to glyph> compatibility-up Py2.6. The whole Py3.0 project is about glyph> eliminating useful libraries and being free of the bonds of glyph> working software. Adding non-essential forward-compatibility to glyph> Py2.6 goes against that philosophy." I think you meant "useless", right? I'm not aware of any proposals to eliminate the os, re or csv modules. ;-) Skip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposed 3.0 compatiblity module
On 1/12/07, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > ISTM, we can decide to limit 3.0's impact to a single compatibility module, > essentially as an alternate set of builtins. > > import __new_builtins__ > for name in 'bytes dict coerce'.split(): # list any new features you want > to support > setattr(__builtins__, name, getattr(__new_builtins__, name)) > > The bytes type would just be the new type. > The dict would have keys=iterkeys, no has_key, etc. > The coerce function would work but have a DeprecationWarning or somesuch. > If you want future division, we already have a mechanism for that. > If you want to eliminate backticks, just grep for them. > If you don't care about 3.0 compatibilty, just don't import the module. Most of these make sense, except for dict: dicts are passed around between modules, and there's little hope that changing the dict type in *your* module will be able to affect the behavior of dicts you receive from *other* modules; and the dicts you create and pass out to other modules will have behavior those other modules don't expect. > Outside of a compatibility module, we can decide to leave Py2.6 unmolested by > Py3.0, so I can stop being cranky. If you're feeling cranky this early in the new year, maybe you should look for reasons outside this list. :-) I'm all for striving for minimal impact. I don't think we can attain zero impact. BTW, a possible alternative would be to strive for code that runs under 2.x, and *after automatic transformation using the 2to3 tool* runs under 3.x, *without mannual patch-up*. That's probably a much lower bar, and it would still mean that developers wishing to maintain code that works with both 2.x/3.x only need to maintain a single version -- the other version could be automatically generated. Since you need to do a lot of testing anyways to make sure you haven't accidentally broken compatibility, the effort would be roughly equivalent to the "identical source" approach that people are advocating so far, and it would probably lift some restrictions. For example, working around print becoming a function would mean no use of print at all when using "identical source"; but that's a transformation that the 2to3 tool can do trivially and perfectly, so the "automatic conversion" approach would enable freely using print statements. A mixture of the two approaches would perhaps work best. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] 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-3000] Warning for 2.6 and greater
Georg Brandl wrote: > Martin v. Löwis schrieb: >> >> What does that mean for the example James gave: if dict.items is >> going to be an iterator in 3.0, what 2.x version can make it return >> an iterator, when it currently returns a list? >> >> There simply can't be a 2.x version that *introduces* the new way, >> as it is not merely a new API, but a changed API. > > Well, that is one of the cases in which that won't be possible ;) Yes - but dict.items() *isn't* going to just return an iterator - it will return a view. For most uses of dict.items(), this means there will not need to be any code change. I'm wondering if we might be going the wrong way about warning about compatibility between 2.x and 3.x. Perhaps it might be better if the 3.0 alpha had a 2.x compatibility mode command-line flag, which is removed late in the beta cycle. Tim Delaney ___ Python-Dev mailing list [email protected] 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-3000] Warning for 2.6 and greater
On 09:04 pm, [EMAIL PROTECTED] wrote: >I'm wondering if we might be going the wrong way about warning about >compatibility between 2.x and 3.x. Perhaps it might be better if the 3.0 >alpha had a 2.x compatibility mode command-line flag, which is removed late >in the beta cycle. Please, no. I don't think command-line flags are going to help much, because the problem is not the complexity of downloading and compiling py3k, it is the complexity of porting software that has modules from a variety of different sources. More importantly however, I'm not even going to be looking into porting anything to py3k until a year or so after its release - and that's only if 2.6 has given me some tools to deal with the transition. The reason I am posting to this thread is that I had *written off py3k entirely* before Anthony started making noises about forward compatibility. The support cycle of Ubuntu Dapper makes it likely that Twisted will be supporting Python 2.4 until at least 2011. I assume 2.5 will last a year after that, so assuming 2.6 has perfect forward compatibility, we'll be looking at a py3k port in early 2013. Features available in the beta releases aren't going to help me there. Plus, this defeats the whole purpose of py3k. Why break compatibility if you're going to include a bunch of gross compatibility code? Compatibility has already been broken in the py3k branch, there's no point in putting it back there. Adding it to 2.x might make sense though. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The bytes type
"A.M. Kuchling" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] | [*] Anyone else keep wanting to write "byte type"? All the other builtin types I can think of are singular. So I think byte should be also. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The bytes type
Terry Reedy wrote: > "A.M. Kuchling" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > | [*] Anyone else keep wanting to write "byte type"? > > All the other builtin types I can think of are singular. So I think byte > should be also. > > The string holds 'a string' (singular), the bytes datatype will hold 'bytes' plural. Bytes is more accurate and I would stumble over byte. Michael Foord > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk > > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The bytes type
"Terry Reedy" <[EMAIL PROTECTED]> wrote: > "A.M. Kuchling" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > | [*] Anyone else keep wanting to write "byte type"? > > All the other builtin types I can think of are singular. So I think byte > should be also. But a "byte" already has a standard definition in the realm of computer science and/or programming, and that definition is singular. No one will think that a byte is a container or a sequence (which is more or less what it is), they will think it is like a C 'char'. Bytes, on the other hand, at least lets people know from the first read that it is a container or sequence of some kind. Of what? Bytes. - Josiah ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The bytes type
On 1/12/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > On 06:49 pm, [EMAIL PROTECTED] wrote: > > >I think we should draw a line in the sand and resolve not to garbage-up > Py2.6. > >The whole Py3.0 project is about eliminating cruft and being free of the > >bonds of backwards compatibility. Adding non-essential cruft to Py2.6 > >goes against that philosophy. > > Emotionally charged like "cruft" and "garbage" are obscuring the issue. > > Let's replace them with equivalents charged in the opposite direction: > > "I think we should draw a line in the sand and resolve not to > compatibility-up Py2.6. The whole Py3.0 project is about eliminating useful > libraries and being free of the bonds of working software. Adding > non-essential forward-compatibility to Py2.6 goes against that philosophy." Well put. Not that I agree. > The benefit (to me, and to many others) of 3.x over 2.x is the promise of > more future maintenance, not the lack of cruft. The benefit (to me, and to many others) of 3.x over 2.x is the promise of getting rid of cruft. If we're going to re-add cruft for the sake of temporary compatibility, we may as well just stick with 2.x. You have to take a quantum leap sometimes or you end up working around the same old mistakes. For instance, getting rid of the str/unicode dichotomy would be a wonderful thing. Then if I make a subclass of string I don't have to think "str or unicode? or two parallel classes?" It'll also eliminate the possibility of a stray 8-bit string containing non-ASCII characters from making your program go kablooie UnicodeDecodeError when it's in a "%" or ".join()", or at least localize the problem to ONE place (the string constructor) where it'll be in every programmer's face and they'll all hopefully learn to handle it consistently and not pass bad strings to other packages. Getting rid of old-style classes would be nice too. -- Mike Orr <[EMAIL PROTECTED]> ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] file(file)
On 12-Jan-2007, at 19:01 , Guido van Rossum wrote:
On 1/12/07, A.M. Kuchling <[EMAIL PROTECTED]> wrote:
Many types in Python are idempotent, so that int(1) works
as expected, float(2.34)==2.34, ''.join('hello')=='hello'
et cetera.
I'm not sure I understand the use case; I don't believe I've ever felt
the need for this.
I have oodles of routines of the form
def foo(thefile):
if type(thefile) == str: thefile = open(thefile)
or
if not hasattr(thefile, 'read'): thefile = open(thefile)
or something similar.
We should also consider the semantics in more detail. Should the seek
position be shared between the two objects? What about buffering?
That's definitely the hard part. But it's somewhat similar to
"normal" mutable objects which are (I think always, right?) shallow
copied when used in a constructor.
--
Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma
Goldman
smime.p7s
Description: S/MIME cryptographic signature
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The bytes type
Raymond Hettinger wrote:
> [A.M. Kuchling]
>> 2.6 wouldn't go changing existing APIs to begin requiring or returning
>> the bytes type[*], of course, but extensions and new modules might use
>> it.
>
> The premise is dubious.
>
> If I am currently maintaining a module, why would I switch to a bytes type
> and forgo compatibility with Py2.5 and prior? I might as well just convert
> it to run on Py3.0 and leave my Py2.5 code as-is for people who want to
> run 2.x.
>
> If I'm writing a new module, what's the point of twisting myself into knots
> to get it to run on both Py2.6 and Py3.0? That just makes coding harder
> (by limiting me to the intersection of the feature sets).
>
> I think we should draw a line in the sand and resolve not to garbage-up Py2.6.
> The whole Py3.0 project is about eliminating cruft and being free of the
> bonds of backwards compatibility. Adding non-essential cruft to Py2.6
> goes against that philosophy.
>
>
> Raymond
+1
For me, the thing that will make porting 2.x to 3.x code easy is to make python
3.0 as clean and organized as you can with excellent documentation. Half-way
and duel-way approaches will probably not help me as much as this.
It also seems to me that instead of putting 3k warnings into 2.X, a external 3k
warnings utility would work just as well. It could generate a list of
("filename", line #, "problem_string") tuples and even cross-reference an
upgrade guide by using the problem_string for advice on each item. The upgrade
guide could contain examples and suggestions learned from experiences at
upgrading pythons library.
Most of the difficulty I have in converting programs is in finding the
information I need. The actual editing is not a problem.
I think making external utilities such as these easy to use will go a long way.
Cheers,
Ron
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] file(file)
On 1/12/07, A.M. Kuchling <[EMAIL PROTECTED]> wrote:
> Forwarded for discussion from http://www.python.org/sf/1633665.
>
> --amk
>
> [forwarded from http://bugs.debian.org/327060]
>
> Many types in Python are idempotent, so that int(1) works
> as expected, float(2.34)==2.34, ''.join('hello')=='hello'
> et cetera.
>
> Why not file()? Currently, file(open(something, 'r')) fails
> with "TypeError: coercing to Unicode: need string or buffer, file found."
>
> Semantically, file(fd) should be equivalent to os.fdopen(fd.fileno())
> or the proposed file.fromfd() (Jp Calderone, Python-dev, 2003).
> You should get another independent
> file object that accesses the same file.
>
For security reasons I might be asking for file's constructor to be
removed from the type for Python source code at some point (it can be
relocated to an extension module if desired). By forcing people to go
through open() to create a file object you can more easily control
read/write access to the file system (assuming the proper importation
of extension modules has been blocked). Not removing the constructor
allows any code that has been explicitly given a file object but not
open() to just get the class and call the constructor to open a new
file.
Don't know when I am gonig to get around to asking for it, though
(still have to finish my security work to have something to present to
python-dev).
-Brett
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] file(file)
On 12:37 am, [EMAIL PROTECTED] wrote: >For security reasons I might be asking for file's constructor to be >removed from the type for Python source code at some point (it can be >relocated to an extension module if desired). By forcing people to go >through open() to create a file object you can more easily control >read/write access to the file system (assuming the proper importation >of extension modules has been blocked). Not removing the constructor >allows any code that has been explicitly given a file object but not >open() to just get the class and call the constructor to open a new >file. This is a general problem with type access. Secure versions of any type should not allow access to the type period. It is hardly unique to files, and is not limited to constructors either. How do you, e.g., allow a restricted piece of code write access to only a specified area of the filesystem? More importantly, given the random behavior that open() will be growing (opening sockets? dynamic dispatch on URL scheme???) file() will likely remain a popular way to be sure you are accessing the filesystem. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] file(file)
On 1/12/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > On 12:37 am, [EMAIL PROTECTED] wrote: > > >For security reasons I might be asking for file's constructor to be > >removed from the type for Python source code at some point (it can be > >relocated to an extension module if desired). By forcing people to go > >through open() to create a file object you can more easily control > >read/write access to the file system (assuming the proper importation > >of extension modules has been blocked). Not removing the constructor > >allows any code that has been explicitly given a file object but not > >open() to just get the class and call the constructor to open a new > >file. > > This is a general problem with type access. Secure versions of any type > should not allow access to the type period. It is hardly unique to files, > and is not limited to constructors either. How do you, e.g., allow a > restricted piece of code write access to only a specified area of the > filesystem? > Wrapper around open() that does proper checking of its arguments. I will be discussing my security stuff at PyCon if you are attending and are interested. -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] file(file)
On 02:42 am, [EMAIL PROTECTED] wrote: >Wrapper around open() that does proper checking of its arguments. I >will be discussing my security stuff at PyCon if you are attending and >are interested. I am both, so I guess I'll see you there :). ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] file(file)
"Jack Jansen" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
|
| On 12-Jan-2007, at 19:01 , Guido van Rossum wrote:
|
| > On 1/12/07, A.M. Kuchling <[EMAIL PROTECTED]> wrote:
| >> Many types in Python are idempotent, so that int(1) works
| >> as expected, float(2.34)==2.34, ''.join('hello')=='hello'
| >> et cetera.
| >
| > I'm not sure I understand the use case; I don't believe I've ever felt
| > the need for this.
|
| I have oodles of routines of the form
| def foo(thefile):
| if type(thefile) == str: thefile = open(thefile)
| or
| if not hasattr(thefile, 'read'): thefile = open(thefile)
| or something similar.
This strikes me as being pretty directly analogous with functions that take
either an iterable or iterator as argument for a parameter, and which start
with
'it = iter(iterable)'. If we follow that analogy, file(fileob) should be
the fileob itself, just as iter(iterator) == iterator.
| > We should also consider the semantics in more detail. Should the seek
| > position be shared between the two objects? What about buffering?
|
| That's definitely the hard part. But it's somewhat similar to
| "normal" mutable objects which are (I think always, right?) shallow
| copied when used in a constructor.
But why, in the normal case, do you want a copy? It seems to me that is
thefile is a file rather than a string, then that is what you want, and you
are asking for
'thefile = file(thefile)' to work just as the iter statement does.
Terry Jan Reedy
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The bytes type
"Josiah Carlson" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] | | "Terry Reedy" <[EMAIL PROTECTED]> wrote: | > "A.M. Kuchling" <[EMAIL PROTECTED]> wrote in message | > news:[EMAIL PROTECTED] | > | [*] Anyone else keep wanting to write "byte type"? | > | > All the other builtin types I can think of are singular. So I think byte | > should be also. | | But a "byte" already has a standard definition in the realm of computer | science and/or programming, and that definition is singular. No one | will think that a byte is a container or a sequence (which is more or | less what it is), they will think it is like a C 'char'. Bytes, on the | other hand, at least lets people know from the first read that it is a | container or sequence of some kind. Of what? Bytes. Okay, this pretty well convinces me. Opinion withdrawn. tjr ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Weekly Python Patch/Bug Summary
Patch / Bug Summary ___ Patches : 421 open ( +3) / 3530 closed ( +8) / 3951 total (+11) Bugs: 963 open ( +4) / 6426 closed (+21) / 7389 total (+25) RFE : 255 open ( +5) / 246 closed ( +1) / 501 total ( +6) New / Reopened Patches __ The Unicode "lazy strings" patches (2007-01-06) http://python.org/sf/1629305 opened by Larry Hastings fast tuple[index] by inlining on BINARY_SUBSCR (2007-01-07) CLOSED http://python.org/sf/1629718 opened by Hirokazu Yamamoto Patch to add tempfile.SpooledTemporaryFile (for #415692) (2007-01-07) http://python.org/sf/1630118 opened by Dustin J. Mitchell Implement named exception cleanup (2007-01-07) CLOSED http://python.org/sf/1630248 opened by Collin Winter Fix crash when replacing sys.stdout in sitecustomize (2007-01-08) http://python.org/sf/1630975 opened by Thomas Wouters SyntaxWarning for backquotes (2007-01-09) http://python.org/sf/1631035 opened by Anthony Baxter implement warnings module in C (2007-01-08) http://python.org/sf/1631171 opened by Neal Norwitz sre module has misleading docs (2007-01-09) http://python.org/sf/1631394 opened by Tom Lynn New exception syntax (2007-01-09) CLOSED http://python.org/sf/1631942 opened by Collin Winter from __future__ import print_function (2007-01-12) http://python.org/sf/1633807 opened by Anthony Baxter Py3k: Fix pybench so it runs (2007-01-13) http://python.org/sf/1634499 opened by Larry Hastings Patches Closed __ Win32: Add bytesobject.c to pythoncore.vcproj (2007-01-04) http://python.org/sf/1628062 closed by loewis Win32: Fix build when you have TortoiseSVN but no .svn/* (2007-01-04) http://python.org/sf/1628061 closed by loewis fast tuple[index] by inlining on BINARY_SUBSCR (2007-01-07) http://python.org/sf/1629718 closed by loewis #1603424 subprocess.py wrongly claims 2.2 compatibility. (2006-12-05) http://python.org/sf/1609282 closed by astrand Implement named exception cleanup (2007-01-07) http://python.org/sf/1630248 closed by collinwinter (py3k) Remove the sets module (2006-06-04) http://python.org/sf/1500611 closed by gvanrossum New exception syntax (2007-01-09) http://python.org/sf/1631942 closed by collinwinter backticks will not be used at all (2007-01-03) http://python.org/sf/1627052 closed by gbrandl New / Reopened Bugs ___ Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1 (2007-01-05) http://python.org/sf/1628484 opened by Bob Atkins Pydoc sets choices for doc locations incorrectly (2007-01-05) http://python.org/sf/1628895 opened by Skip Montanaro xml.dom.minidom parse bug (2007-01-05) CLOSED http://python.org/sf/1628902 opened by Pierre Imbaud clarify 80-char limit (2007-01-05) http://python.org/sf/1628906 opened by Jim Jewett inspect trouble when source file changes (2007-01-05) http://python.org/sf/1628987 opened by phil Incorrect type in PyDict_Next() example code (2007-01-05) http://python.org/sf/1629125 opened by Jason Evans email._parseaddr AddrlistClass bug (2007-01-06) http://python.org/sf/1629369 opened by Tokio Kikuchi array.array borks on deepcopy (2006-08-24) CLOSED http://python.org/sf/1545837 reopened by nnorwitz documentation of email.utils.parsedate is confusing (2007-01-06) http://python.org/sf/1629566 opened by Nicholas Riley Backward incompatibility in logging.py (2006-10-02) CLOSED http://python.org/sf/1569622 reopened by mklaas doc error for re.sub (2007-01-08) CLOSED http://python.org/sf/1630511 opened by Keith Briggs doc misleading in re.compile (2007-01-08) http://python.org/sf/1630515 opened by Keith Briggs Seg fault in readline call. (2007-01-08) http://python.org/sf/1630794 opened by gnovak fnmatch.translate undocumented (2007-01-08) http://python.org/sf/1630844 opened by Gabriel Genellina PyLong_AsLong doesn't check tp_as_number (2007-01-08) CLOSED http://python.org/sf/1630863 opened by Roger Upole Garbage output to file of specific size (2007-01-08) http://python.org/sf/1630894 opened by Michael Culbertson email.Generators does not separates headers with "\r\n" (2005-11-05) http://python.org/sf/1349106 reopened by bwarsaw Discrepancy between iterating empty and non-empty deques (2007-01-09) CLOSED http://python.org/sf/1631769 opened by Christos Georgiou logging.config.fileConfig doesn't clear logging._handlerList (2007-01-10) CLOSED http://python.org/sf/1632328 opened by Stefan H. Holek Hangs with 100% CPU load for certain regexes (2007-01-11) CLOSED http://python.org/sf/1633583 opened by Matthias Klose using locale does not display the intended behavior (2007-01-11) http://python.org/sf/1633600 opened by Matthias Klose logging module / wro
