Re: [Python-Dev] Improve open() to support reading file starting with an unicode BOM
If Python should support BOM when reading text files, it should also be able to *write* such files. An encoding="BOM" argument wouldn't help here, because it does not specify which encoding to use actually: UFT-8, UTF-16-LE or what? That would be a point against encoding="BOM" and pro an additional keyword argument "use_bom" or whatever with the following values: None: default (old) behaviour: don't handle BOM at all True: reading: expect BOM (raising an exception if it's missing). The encoding argument must be None or it must match the encoding implied by the BOM writing: write a BOM. The encoding argument must be one of the UTF encodings. False: reading: If a BOM is present, use it to determine the file encoding. The encoding argument must be None or it must match the encoding implied by the BOM. (*) Otherwise, use the encoding argument to determine the encoding. writing: do not write a BOM. Use the encoding argument. (*) This is a question of taste. I think some people would prefer a fourth value "AUTO" instead, or to swap the behaviour of None and False. Henning P.S. To make things worse, I have sometimes seen XML files with a UTF-8 BOM, but an XML encoding declaration of "iso-8859-1". For such files, whatever you guess will be wrong anyway... ___ 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] Improve open() to support reading file starting with an unicode BOM
On Sun, Jan 10, 2010 at 12:10, Henning von Bargen wrote: > If Python should support BOM when reading text files, > it should also be able to *write* such files. That's what I thought too. Turns out the UTF-16 does write such a mark. You also have the constants in the codecs module, so you can write the utf-16-le BOM and then use the utf-16-le encoding if you want to be sure you write utf-16-le, and the same with BE, of course. I still think now using BOM's when determining the file format can be seen as a bug, though, so I don't think the API needs to change at all. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64 ___ 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] Fwd: [Python-checkins] r77402 - in python/trunk: Doc/library/warnings.rst Lib/test/test_ascii_formatd.py Lib/test/test_exceptions.py Lib/warnings.py Misc/NEWS Python/_warnings.c
Nick Coghlan thought I should forward this to python-dev so people are aware
of this change and why it occurred (plus it indirectly informs Guido I
finally finished the work).
-- Forwarded message --
From: brett.cannon
Date: Sat, Jan 9, 2010 at 18:56
Subject: [Python-checkins] r77402 - in python/trunk:
Doc/library/warnings.rst Lib/test/test_ascii_formatd.py
Lib/test/test_exceptions.py Lib/warnings.py Misc/NEWS Python/_warnings.c
To: python-check...@python.org
Author: brett.cannon
Date: Sun Jan 10 03:56:19 2010
New Revision: 77402
Log:
DeprecationWarning is now silent by default.
This was originally suggested by Guido, discussed on the stdlib-sig mailing
list, and given the OK by Guido directly to me. What this change essentially
means is that Python has taken a policy of silencing warnings that are only
of interest to developers by default. This should prevent users from seeing
warnings which are triggered by an application being run against a new
interpreter before the app developer has a chance to update their code.
Closes issue #7319. Thanks to Antoine Pitrou, Ezio Melotti, and Brian Curtin
for helping with the issue.
Modified:
python/trunk/Doc/library/warnings.rst
python/trunk/Lib/test/test_ascii_formatd.py
python/trunk/Lib/test/test_exceptions.py
python/trunk/Lib/warnings.py
python/trunk/Misc/NEWS
python/trunk/Python/_warnings.c
Modified: python/trunk/Doc/library/warnings.rst
==
--- python/trunk/Doc/library/warnings.rst (original)
+++ python/trunk/Doc/library/warnings.rst Sun Jan 10 03:56:19 2010
@@ -59,7 +59,7 @@
| :exc:`UserWarning` | The default category for :func:`warn`.
|
+--+---+
| :exc:`DeprecationWarning`| Base category for warnings about
deprecated |
-| | features.
|
+| | features (ignored by default).
|
+--+---+
| :exc:`SyntaxWarning` | Base category for warnings about
dubious |
| | syntactic features.
|
@@ -89,6 +89,9 @@
standard warning categories. A warning category must always be a subclass
of
the :exc:`Warning` class.
+.. versionchanged:: 2.7
+ :exc:`DeprecationWarning` is ignored by default.
+
.. _warning-filter:
@@ -148,14 +151,6 @@
:mod:`warnings` module parses these when it is first imported (invalid
options
are ignored, after printing a message to ``sys.stderr``).
-The warnings that are ignored by default may be enabled by passing
:option:`-Wd`
-to the interpreter. This enables default handling for all warnings,
including
-those that are normally ignored by default. This is particular useful for
-enabling ImportWarning when debugging problems importing a developed
package.
-ImportWarning can also be enabled explicitly in Python code using::
-
- warnings.simplefilter('default', ImportWarning)
-
.. _warning-suppress:
@@ -226,6 +221,37 @@
entries from the warnings list before each new operation).
+Updating Code For New Versions of Python
+
+
+Warnings that are only of interest to the developer are ignored by default.
As
+such you should make sure to test your code with typically ignored warnings
+made visible. You can do this from the command-line by passing
:option:`-Wd`
+to the interpreter (this is shorthand for :option:`-W default`). This
enables
+default handling for all warnings, including those that are ignored by
default.
+To change what action is taken for encountered warnings you simply change
what
+argument is passed to :option:`-W`, e.g. :option:`-W error`. See the
+:option:`-W` flag for more details on what is possible.
+
+To programmatically do the same as :option:`-Wd`, use::
+
+ warnings.simplefilter('default')
+
+Make sure to execute this code as soon as possible. This prevents the
+registering of what warnings have been raised from unexpectedly influencing
how
+future warnings are treated.
+
+Having certain warnings ignored by default is done to prevent a user from
+seeing warnings that are only of interest to the developer. As you do not
+necessarily have control over what interpreter a user uses to run their
code,
+it is possible that a new version of Python will be released between your
+release cycles. The new interpreter release could trigger new warnings in
your
+code that were not there in an older interpreter, e.g.
+:exc:`DeprecationWarning` for a module that you are using. While you as a
+developer want to be notified that your code is using a deprecated module,
to a
+user this information is essentially noise and provides no benefit to them.
+
+
.. _warning-functions:
Available Functions
Modified: python/trunk/Lib/test/test_ascii_formatd.py
Re: [Python-Dev] Fwd: [Python-checkins] r77402 - in python/trunk: Doc/library/warnings.rst Lib/test/test_ascii_formatd.py Lib/test/test_exceptions.py Lib/warnings.py Misc/NEWS Python/_warnings.c
Hi, Le dimanche 10 janvier 2010 19:51:26, Brett Cannon a écrit : > Nick Coghlan thought I should forward this to python-dev so people are > aware of this change and why it occurred (plus it indirectly informs Guido > I finally finished the work). Thanks to copy this mail to the python-dev mailing list. What is the recommanded way to get the previous behaviour (print deprecation warnings once)? Is there a command line option? Is it "-W default"? -- Victor Stinner http://www.haypocalc.com/ ___ 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] Fwd: [Python-checkins] r77402 - in python/trunk: Doc/library/warnings.rst Lib/test/test_ascii_formatd.py Lib/test/test_exceptions.py Lib/warnings.py Misc/NEWS Python/_warnings.c
2010/1/10 Victor Stinner : > Hi, > > Le dimanche 10 janvier 2010 19:51:26, Brett Cannon a écrit : >> Nick Coghlan thought I should forward this to python-dev so people are >> aware of this change and why it occurred (plus it indirectly informs Guido >> I finally finished the work). > > Thanks to copy this mail to the python-dev mailing list. > > What is the recommanded way to get the previous behaviour (print deprecation > warnings once)? Is there a command line option? Is it "-W default"? That commit conveniently adds documentation answering that question. :) -- Regards, Benjamin ___ 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] [RELEASED] Python 2.7 alpha 2
Benjamin Peterson wrote: > On behalf of the Python development team, I'm gleeful to announce > the second alpha release of Python 2.7. Thanks to everyone who contributed. > Python 2.7 is scheduled to be the last major version in the 2.x > series. Has this really been decided already? Maybe I missed it. In my opinion, it does Python's reputation harm to make such a statement. Conservative users (probably the vast majority of Python users) don't like to hear that software they are considering using is nearing the end of its life. What does it gain us to announce that the 2.x branch is dead aside from bugfixes? I propose that the 2.x branch be treated like 2.x.y branches: as long as there is sufficient volunteer labour, it should continue to live. In order to avoid wasted development effort, it would be prudent to announce that unless a 2.8 release manager steps up, whatever is committed to the 2.x branch after the 2.7 release may never get released. Said another way, it's okay for the Python developers to decide to abandon 2.x and put their efforts into 3.x. It's not okay for them to prevent others from continuing to work on 2.x or to somehow make 2.x look worse so 3.x looks better. Python 3 needs to stand on its own terms and I'm confident it can. Best regards, Neil ___ 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] [RELEASED] Python 2.7 alpha 2
On Sun, Jan 10, 2010 at 11:30, Neil Schemenauer wrote: > Benjamin Peterson wrote: > > On behalf of the Python development team, I'm gleeful to announce > > the second alpha release of Python 2.7. > > Thanks to everyone who contributed. > > > Python 2.7 is scheduled to be the last major version in the 2.x > > series. > > Has this really been decided already? Maybe I missed it. More or less. It was first discussed at the language summit last year and has come up here a couple of times. If needed we can make it official in terms of lifetime of 2.7, etc. at the language summit this year. > In my > opinion, it does Python's reputation harm to make such a statement. > Conservative users (probably the vast majority of Python users) > don't like to hear that software they are considering using is > nearing the end of its life. What does it gain us to announce that > the 2.x branch is dead aside from bugfixes? > > I propose that the 2.x branch be treated like 2.x.y branches: as > long as there is sufficient volunteer labour, it should continue to > live. In order to avoid wasted development effort, it would be > prudent to announce that unless a 2.8 release manager steps up, > whatever is committed to the 2.x branch after the 2.7 release may > never get released. > > Said another way, it's okay for the Python developers to decide to > abandon 2.x and put their efforts into 3.x. It's not okay for them > to prevent others from continuing to work on 2.x or to somehow make > 2.x look worse so 3.x looks better. Python 3 needs to stand on its > own terms and I'm confident it can. > I don't think ending the 2.x series at 2.7 makes it look bad compared to 3.2; it's simply the end of a development line like any other software project. I suspect 2.7 will have a protracted bugfix window because so much code runs on 2.x exclusively at the moment. And if core developers want to continue to backport fixes past two years from release they can (or however long we decide to officially support 2.7). No one is saying people still can't work on the code, just that python-dev as an entity is not going to focus its effort on the 2.x series anymore and people should not rely upon us to continue to focus new development efforts in that series. If there are core developers who want to continue to do bugfix releases then that's fine and I am happy to flag patches as needing backports and let other's do the work after the standard two year maintenance cycle, but I know I do not want to be held accountable as a core developer to keep the 2.x going indefinitely. Maintaining four branches is enough of a reason in my book to not keep the 2.x series going. If there really is an outcry on this we can re-visit the issue, but as of right now we need to move forward at some point and 2.7 seems like that good point. -Brett ___ 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] [RELEASED] Python 2.7 alpha 2
Neil Schemenauer wrote: > In order to avoid wasted development effort, it would be > prudent to announce that unless a 2.8 release manager steps up, > whatever is committed to the 2.x branch after the 2.7 release may > never get released. The announcement is precisely to avoid the situation where people commit new features to the 2.x main line of development (after the 2.7 maintenance branch is created) in the expectation that they will be released as part of a hypothetical 2.8 release. Whether that info needs to be in each and every 2.7 announcement... probably not. It isn't really info for users of Python, just for developers of Python. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ 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] topics I plan to discuss at the language summit
Michael has given me the hg transition/stdlib time slot at the language summit this year. In regards to that I plan to lead a discussion on: * where we are at w/ the Hg transition (Dirkjan should be there and I did a blog post on this topic recently: http://sayspy.blogspot.com/2010/01/where-hg-transition-stands.html) * argparse (PEP 389) * brief mention on still wanting to break out the stdlib from CPython * an official policy on extension modules? (i.e. must have a pure Python implementation which can mean a ctypes implementation unless given an explicit waiver) That's everything from a stdlib perspective. I have half-baked ideas, but nothing concrete enough to bring up unless people really want to discuss stuff like how to potentially standardize module deprecation warnings, etc. In terms of me personally, I do plan to bring up at some point during the summit these points which don't squarely fit during my time slot: * an official unofficial policy on how new proposed features should come to us (i.e. working code to python-ideas with a shell of a PEP that includes abstract and motivation -> hashed out PEP to python-dev -> pronouncement) * any changes needed to the issue tracker to help with the workflow? (stage field seems like a failed experiment and we now have several effective triage people who can help w/ guiding changes) If there is something missing from the stdlib discussion that you think should be brought up at the summit let me know. And if there is something here you want to discuss before the summit let me know and I can start a separate thread on it. -Brett ___ 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] topics I plan to discuss at the language summit
On Sun, Jan 10, 2010 at 21:25, Brett Cannon wrote: > Michael has given me the hg transition/stdlib time slot at the language > summit this year. In regards to that I plan to lead a discussion on: > * where we are at w/ the Hg transition (Dirkjan should be there and I did a > blog post on this topic recently: > http://sayspy.blogspot.com/2010/01/where-hg-transition-stands.html) Unfortunately my flight doesn't land until about the time the Mercurial slot ends, so while I'll be there later on that afternoon for sprinting or questions or anything, I won't be at the actual Mercurial talk at the summit. Cheers, Dirkjan ___ 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] topics I plan to discuss at the language summit
On 10/01/2010 21:52, Dirkjan Ochtman wrote: On Sun, Jan 10, 2010 at 21:25, Brett Cannon wrote: Michael has given me the hg transition/stdlib time slot at the language summit this year. In regards to that I plan to lead a discussion on: * where we are at w/ the Hg transition (Dirkjan should be there and I did a blog post on this topic recently: http://sayspy.blogspot.com/2010/01/where-hg-transition-stands.html) Unfortunately my flight doesn't land until about the time the Mercurial slot ends, so while I'll be there later on that afternoon for sprinting or questions or anything, I won't be at the actual Mercurial talk at the summit. We will probably be in 'open discussion' when you arrive so it will still be good to hear from you on the topic and there maybe questions that can't be answered until you arrive... :-) Michael Cheers, Dirkjan ___ 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/fuzzyman%40voidspace.org.uk -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog ___ 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] [RELEASED] Python 2.7 alpha 2
> I propose that the 2.x branch be treated like 2.x.y branches: as > long as there is sufficient volunteer labour, it should continue to > live. In order to avoid wasted development effort, it would be > prudent to announce that unless a 2.8 release manager steps up, > whatever is committed to the 2.x branch after the 2.7 release may > never get released. I think it's more difficult than that. It also takes developer effort to *commit* to the trunk. So if the trunk continued to live, would it still be ok if I closed a 2.x feature request as "won't fix", or only committed the new feature to the 3.x branch? As for old branches: they *don't* live in the way you claim (i.e. remain open with changes potentially just not released). Instead, at some point, they are frozen to bug-fix only, then to security-fix only, and then to no change at all. Regards, Martin ___ 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] [RELEASED] Python 2.7 alpha 2
> The announcement is precisely to avoid the situation where people commit > new features to the 2.x main line of development (after the 2.7 > maintenance branch is created) in the expectation that they will be > released as part of a hypothetical 2.8 release. > > Whether that info needs to be in each and every 2.7 announcement... > probably not. It isn't really info for users of Python, just for > developers of Python. I think the announcement is indeed also for the users, and I would prefer it to stay in the release announcements, so that people will know for sure (and speak up) before the 2.7 release happens. As for decisions: I don't think there was an official BDFL pronouncent, but I recall Guido posting a message close to that, proposing that 2.7 will be a release that will see bug fix releases for an indefinite period of time (where indefinite != infinite). This was shortly after him proposing that perhaps we shouldn't make a 2.7 release at all, and stop at 2.6. As for such a decision giving a bad light on Python: I don't think that will be the case. Instead, I hear many users surprised for how long we have been maintaining to parallel versions - "that must have taken a lot of effort". So everybody will likely understand that enough is enough. Regards, Martin ___ 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] Data descriptor doc/implementation inconsistency
Consider this program:
class Descr(object):
def __init__(self, name):
self.name = name
def __set__(self, instance, what):
instance.__dict__[self.name] = what
class X(object):
attr = Descr("attr")
x = X()
print(x.attr)
x.attr = 42
print(x.attr)
It gives in output:
<__main__.Descr object at 0x7fe1c9b28150>
42
The documentation [1] says that Descr is a data descriptor because it
defines the __set__ method. It also states that data descriptors
always override the value in the instance dictionary. So, the second
line should also be the descriptor object according to the
documentation.
My question is: Is this a doc bug or a implementation bug? If the
former, it will be the description of a data descriptor much less
consistent, since it will require that a __get__ method be present,
too. If the latter, the fix may break some programs relying on the
ability to "cache" a value in the instance dictionary.
[1] http://docs.python.org/reference/datamodel#invoking-descriptors
--
Regards,
Benjamin
___
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] Data descriptor doc/implementation inconsistency
Hi,
2010/1/11 Benjamin Peterson :
> Consider this program:
>
> class Descr(object):
> def __init__(self, name):
> self.name = name
> def __set__(self, instance, what):
> instance.__dict__[self.name] = what
>
> class X(object):
> attr = Descr("attr")
>
> x = X()
> print(x.attr)
> x.attr = 42
> print(x.attr)
>
> It gives in output:
>
> <__main__.Descr object at 0x7fe1c9b28150>
> 42
>
> The documentation [1] says that Descr is a data descriptor because it
> defines the __set__ method. It also states that data descriptors
> always override the value in the instance dictionary. So, the second
> line should also be the descriptor object according to the
> documentation.
>
> My question is: Is this a doc bug or a implementation bug? If the
> former, it will be the description of a data descriptor much less
> consistent, since it will require that a __get__ method be present,
> too. If the latter, the fix may break some programs relying on the
> ability to "cache" a value in the instance dictionary.
>
> [1] http://docs.python.org/reference/datamodel#invoking-descriptors
Quoting the documentation:
"""Normally, data descriptors define both __get__() and __set__(),
while non-data descriptors have just the __get__() method.
"""
Your example is neither a data descriptor nor a non-data descriptor...
The thing that worries me a bit is the "x.attr" returning the Descr
object. Descriptors should remain at the class level, and instance
should only see values. I'd prefer an AttributeError in this case.
--
Amaury Forgeot d'Arc
___
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] Data descriptor doc/implementation inconsistency
2010/1/10 Amaury Forgeot d'Arc : > Quoting the documentation: > """Normally, data descriptors define both __get__() and __set__(), > while non-data descriptors have just the __get__() method. > """ > Your example is neither a data descriptor nor a non-data descriptor... See the footnote: http://docs.python.org/reference/datamodel#id7 > > The thing that worries me a bit is the "x.attr" returning the Descr > object. Descriptors should remain at the class level, and instance > should only see values. I'd prefer an AttributeError in this case. Far too late for that, I'm afraid. -- Regards, Benjamin ___ 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] [RELEASED] Python 2.7 alpha 2
On Sun, Jan 10, 2010 at 12:09:08PM -0800, Brett Cannon wrote: > I don't think ending the 2.x series at 2.7 makes it look bad > compared to 3.2; it's simply the end of a development line like > any other software project. I suspect 2.7 will have a protracted > bugfix window because so much code runs on 2.x exclusively at the > moment. I would guess over 99% of all Python code written doesn't run on Python 3. Given that, I think it is premature to close the door on new major versions of Python 2.x. Also, we as a project should be careful not to present the image that Python 2.x will not be supported in the future. > If there really is an outcry on this we can re-visit the issue, > but as of right now we need to move forward at some point and 2.7 > seems like that good point. I think that's bad PR. If I had a successful product, I would not announce its end of life just to see how many customers scream and then decide if I should devote more resources to continue maintaining it. IMHO, the release notes should say something like: After the Python 2.7 release, the focus of Python development will be on Python 3. There will continue to be maintainance releases of Python 2.x. trying-to-head-off-the-python-is-dying-meme-ly y'rs Neil ___ 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] [RELEASED] Python 2.7 alpha 2
On 1/10/2010 8:44 PM, Neil Schemenauer wrote: On Sun, Jan 10, 2010 at 12:09:08PM -0800, Brett Cannon wrote: I don't think ending the 2.x series at 2.7 makes it look bad compared to 3.2; it's simply the end of a development line like any other software project. I suspect 2.7 will have a protracted bugfix window because so much code runs on 2.x exclusively at the moment. I would guess over 99% of all Python code written doesn't run on Python 3. If the removal of old features had been done in the 2.x series, as once planned (Guido originally proposed removing the old meaning of int / int in 2.5) the same more or less would be true of 2.7. It is past time for other old and now duplicated features to be removed also. Given that, I think it is premature to close the door on new major versions of Python 2.x. Also, we as a project should be careful not to present the image that Python 2.x will not be supported in the future. If there really is an outcry on this we can re-visit the issue, but as of right now we need to move forward at some point and 2.7 seems like that good point. I think that's bad PR. If I had a successful product, I would not announce its end of life just to see how many customers scream and then decide if I should devote more resources to continue maintaining it. Python is not being ended, but upgraded (with bloating duplications removed). Think of 3.1 as 2.8 with a new name. tjr ___ 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] Data descriptor doc/implementation inconsistency
> Date: Mon, 11 Jan 2010 01:51:09 +0100
> From: "Amaury Forgeot d'Arc"
> To: Benjamin Peterson
> Cc: Python Dev
> Subject: Re: [Python-Dev] Data descriptor doc/implementation
> inconsistency
> Message-ID:
>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Hi,
>
> 2010/1/11 Benjamin Peterson :
>> Consider this program:
>>
>> class Descr(object):
>> ? ?def __init__(self, name):
>> ? ? ? ?self.name = name
>> ? ?def __set__(self, instance, what):
>> ? ? ? ?instance.__dict__[self.name] = what
>>
>> class X(object):
>> ? ?attr = Descr("attr")
>>
>> x = X()
>> print(x.attr)
>> x.attr = 42
>> print(x.attr)
>>
>> It gives in output:
>>
>> <__main__.Descr object at 0x7fe1c9b28150>
>> 42
>>
>> The documentation [1] says that Descr is a data descriptor because it
>> defines the __set__ method. It also states that data descriptors
>> always override the value in the instance dictionary. So, the second
>> line should also be the descriptor object according to the
>> documentation.
>>
>> My question is: Is this a doc bug or a implementation bug? If the
>> former, it will be the description of a data descriptor much less
>> consistent, since it will require that a __get__ method be present,
>> too. If the latter, the fix may break some programs relying on the
>> ability to "cache" a value in the instance dictionary.
>>
>> [1] http://docs.python.org/reference/datamodel#invoking-descriptors
>
> Quoting the documentation:
> """Normally, data descriptors define both __get__() and __set__(),
> while non-data descriptors have just the __get__() method.
> """
> Your example is neither a data descriptor nor a non-data descriptor...
Actually, there is this footnote [1]:
""" A descriptor can define any combination of __get__(), __set__()
and __delete__(). If it does not define __get__(), then accessing the
attribute even on an instance will return the descriptor object
itself. If the descriptor defines __set__() and/or __delete__(), it is
a data descriptor; if it defines neither, it is a non-data descriptor.
"""
Which would mean Descr is actually a data descriptor without a
__get__(), so x.attr should always return the descriptor object itself
(at least in the docs).
> The thing that worries me a bit is the "x.attr" returning the Descr
> object. Descriptors should remain at the class level, and instance
> should only see values. I'd prefer an AttributeError in this case.
>
> --
> Amaury Forgeot d'Arc
[1] http://docs.python.org/reference/datamodel#id7
--
Lukasz Rekucki
___
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] [RELEASED] Python 2.7 alpha 2
On Sun, Jan 10, 2010 at 17:44, Neil Schemenauer wrote: > On Sun, Jan 10, 2010 at 12:09:08PM -0800, Brett Cannon wrote: > > I don't think ending the 2.x series at 2.7 makes it look bad > > compared to 3.2; it's simply the end of a development line like > > any other software project. I suspect 2.7 will have a protracted > > bugfix window because so much code runs on 2.x exclusively at the > > moment. > > I would guess over 99% of all Python code written doesn't run on > Python 3. Given that, I think it is premature to close the door on > new major versions of Python 2.x. Well yeah; Python 3.0 is just over a year old with 3.1 -- the first robust 3.x release - is about six months old. From the beginning uptake was expected to take years, not months, so saying that 3.x is not popular enough seems premature. > Also, we as a project should be > careful not to present the image that Python 2.x will not be > supported in the future. > No one has said bugfixes will cease. > > > If there really is an outcry on this we can re-visit the issue, > > but as of right now we need to move forward at some point and 2.7 > > seems like that good point. > > I think that's bad PR. If I had a successful product, I would not > announce its end of life just to see how many customers scream and > then decide if I should devote more resources to continue > maintaining it. > > I never said that I wanted to make this announcement specifically to provoke outcries. I said if there happened to be outcries we could possibly visit the issue again. Basically I was being considerate and trying to leave the door open to discuss things in the future even though I don't see the situation changing. > IMHO, the release notes should say something like: > > After the Python 2.7 release, the focus of Python development > will be on Python 3. There will continue to be maintainance > releases of Python 2.x. > No because that suggests new features will be coming to 2.x which is not going to happen. If you want to say there will be continual bugfix releases for 2.7 as is par the course for Python and that the number of bugfix releases might be more than normal then I am okay with that. > > > trying-to-head-off-the-python-is-dying-meme-ly y'rs Neil > That came and went already a couple months ago when we discussed stopping at 2.6 instead of 2.7 (see the various threads at http://mail.python.org/pipermail/python-dev/2009-November/thread.html). -Brett ___ 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] [RELEASED] Python 2.7 alpha 2
On Sun, Jan 10, 2010 at 07:46:04PM -0800, Brett Cannon wrote: > On Sun, Jan 10, 2010 at 17:44, Neil Schemenauer wrote: > > After the Python 2.7 release, the focus of Python development > > will be on Python 3. There will continue to be maintainance > > releases of Python 2.x. > > No because that suggests new features will be coming to 2.x which is not > going to happen. If you want to say there will be continual bugfix releases > for 2.7 as is par the course for Python and that the number of bugfix > releases might be more than normal then I am okay with that. Are you are saying that if someone steps up to merge the Unladen Swallow features into a 2.8 release and someone also steps up to cut the release that they will be prevented from doing so? Also, are you presuming to channel the BDFL or was this dicussed somewhere other than python-dev? Maybe I'm overreacting but I get the feeling that the larger and less active segment of the Python develpment team hasn't been involved in these decisions. Best regards, Neil ___ 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] [RELEASED] Python 2.7 alpha 2
On Mon, Jan 11, 2010 at 12:02:01AM +0100, "Martin v. Löwis" wrote: > [...] would it still be ok if I closed a 2.x feature request as > "won't fix", or only committed the new feature to the 3.x branch? Yes. Non-bugfix development on 2.x would optional (i.e. done by people who want to spend the time). Since language changes are now out (an initiative I completely support), the majority of non-bugfix changes would be optimizations and platform porting. Regards, Neil ___ 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] [RELEASED] Python 2.7 alpha 2
On Sun, Jan 10, 2010 at 20:05, Neil Schemenauer wrote: > On Sun, Jan 10, 2010 at 07:46:04PM -0800, Brett Cannon wrote: > > On Sun, Jan 10, 2010 at 17:44, Neil Schemenauer wrote: > > > After the Python 2.7 release, the focus of Python development > > > will be on Python 3. There will continue to be maintainance > > > releases of Python 2.x. > > > > No because that suggests new features will be coming to 2.x which is not > > going to happen. If you want to say there will be continual bugfix > releases > > for 2.7 as is par the course for Python and that the number of bugfix > > releases might be more than normal then I am okay with that. > > Are you are saying that if someone steps up to merge the Unladen > Swallow features into a 2.8 release and someone also steps up to cut > the release that they will be prevented from doing so? > > I honestly don't know, but it's a possibility just like any other new feature request. If people start taking the carrots we have added to 3.x and backporting them to keep the 2.x series alive you are essentially making the 3.x DOA by negating its benefits which I personally don't agree with. > Also, are you presuming to channel the BDFL or was this dicussed > somewhere other than python-dev? This was discussed; see the November 2009 threads. Guido actually suggested ending the 2.x branch at 2.6 until people spoke up about the amount of stuff already backported to 2.7 from 3.x because it was being assumed to be the end of the series to warrant keeping it to help transition to 2.7. > Maybe I'm overreacting but I get > the feeling that the larger and less active segment of the Python > develpment team hasn't been involved in these decisions. > This all came up in November from the 3rd through the 6th (four days) over a ton of email traffic. This was not a snap decision but a heated discussion where even Guido participated that culminated with the decision to stop at 2.7 for the 2.x series; this was not a smoked-filled room decision. I'm sorry if people missed it when they weren't looking, but python-dev is supposed to be the place to watch for this kind of stuff. I don't know how else to bring this stuff to people's attention short of also on python-committers, but developers are basically expected to be on both lists so I don't see where anyone did anything wrong in terms of informing developers. -Brett ___ 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] [RELEASED] Python 2.7 alpha 2
On Sun, Jan 10, 2010 at 09:06:15PM -0800, Brett Cannon wrote: > If people start taking the carrots we have added to 3.x and > backporting them to keep the 2.x series alive you are essentially > making the 3.x DOA by negating its benefits which I personally > don't agree with. I think we have got to the heart of our disagreement. Assume that some superhuman takes all the backwards compatible goodies from 3.x and merges them into 2.x. If that really would kill off Python 3 then I would proclaim it a project that deserved to die. Why should the backwards incompatible changes be endured if they cannot justify their existance by the benefit they provide? I guess I have more confidence in Python 3 than you do. I don't see why Python 2.x needs to be artificially limited so that Python 3 can benefit. Regards, Neil ___ 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] [RELEASED] Python 2.7 alpha 2
On Sun, Jan 10, 2010 at 21:27, Neil Schemenauer wrote: > On Sun, Jan 10, 2010 at 09:06:15PM -0800, Brett Cannon wrote: > > If people start taking the carrots we have added to 3.x and > > backporting them to keep the 2.x series alive you are essentially > > making the 3.x DOA by negating its benefits which I personally > > don't agree with. > > I think we have got to the heart of our disagreement. Assume that > some superhuman takes all the backwards compatible goodies from 3.x > and merges them into 2.x. If that really would kill off Python 3 > then I would proclaim it a project that deserved to die. Why should > the backwards incompatible changes be endured if they cannot justify > their existance by the benefit they provide? > > When I said "carrots" I meant everything that makes Python 3 the best version of Python, including the backward-incompatible changes. I guess I have more confidence in Python 3 than you do. I don't see > why Python 2.x needs to be artificially limited so that Python 3 can > benefit. > I don't view it as artificial but simply a focusing of the development team on what has been determined as the future of Python by Guido and letting go of the past. IMO keeping Python 2.x around past 2.7 is the equivalent of python-dev saying "Python 3 is the future, but we are keeping the old Python 2.x around because we don't have *that* much faith in the future we have laid out". That's poison to Python 3 by showing a lack of confidence in the direction that the BDFL and python-dev as a group has chosen. Now I could be wrong and there could actually be a large number of active contributors who want to keep the 2.x series going, but based on the discussion that occurred the last time this came up I believe the guys who are keeping Python running are ready to move on. -Brett ___ 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] [RELEASED] Python 2.7 alpha 2
On Mon, Jan 11, 2010 at 06:27, Neil Schemenauer wrote: > I think we have got to the heart of our disagreement. Assume that > some superhuman takes all the backwards compatible goodies from 3.x > and merges them into 2.x. The superhumans of core developers pretty much already have. That's pretty much 2.7 you are talking about. :) -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64 ___ 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
