Re: [Python-Dev] The docstring hack for signature information has to go

Am 05.02.2014 14:52, schrieb "Martin v. Löwis": > Am 03.02.14 15:43, schrieb Larry Hastings: >> A: We create a PyMethodDefEx structure with an extra field: "const char >> *signature". We add a new METH_SIGNATURE (maybe just METH_SIG?) flag to >> the flags, indicating that this is an extended struc

[Python-Dev] [RELEASED] Python 3.3.4

http://bugs.python.org/ Enjoy! - -- Georg Brandl, Release Manager georg at python.org (on behalf of the entire python-dev team and 3.3's contributors) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlL5PMwACgkQN9GcIYhpnLCv4wCePNVqwsOYCHdJBi

Re: [Python-Dev] Possible major bug with zipimport on Windows in Python 3.3.4

Am 15.02.2014 23:19, schrieb Paul Moore: > On 13 February 2014 20:58, Paul Moore wrote: >> On 13 February 2014 20:54, Donald Stufft wrote: >>> >>> On Feb 13, 2014, at 3:53 PM, Paul Moore wrote: >>> Can someone please take a look at http://bugs.python.org/issue20621 for me? It appears t

Re: [Python-Dev] CLA link from bugs.python.org

Am 16.02.2014 09:40, schrieb Ezio Melotti: > Hi, > > On Sun, May 5, 2013 at 7:45 AM, Ezio Melotti wrote: >> Hi, >> >> On Sun, May 5, 2013 at 4:23 AM, Tim Delaney >> wrote: >>> It appears there's no obvious link from bugs.python.org to the contributor >>> agreement - you need to go via the unint

Re: [Python-Dev] pootle.python.org is down

Am 16.02.2014 16:32, schrieb Benjamin Peterson: > On Sun, Feb 16, 2014, at 06:52 AM, A.M. Kuchling wrote: >> I came across http://bugs.python.org/issue13663, which is about a >> pootle.python.org installation. http://pootle.python.org/ currently >> returns a 500. Are we still using Pootle, or sho

Re: [Python-Dev] Possible major bug with zipimport on Windows in Python 3.3.4

Am 16.02.2014 21:14, schrieb Terry Reedy: > On 2/16/2014 2:52 PM, Serhiy Storchaka wrote: >> 16.02.14 10:19, Georg Brandl написав(ла): >>> As soon as a patch has been provided and tested, I will make a schedule >>> for 3.3.5 including the fix. Until then, using 3.3

Re: [Python-Dev] Python 3.4: What to do about the Derby patches

cifically, I propose >>> we ship 3.4.1 two months after 3.4.0. I figure we would release 3.4.1 >>> rc1 on Sunday May 4th, and 3.4.1 final on Sunday May 18th. >> >> How this will affect the schedule for 3.3.x? Will it accelerately switched to >> security-only fix m

Re: [Python-Dev] cpython: Doc: do not rely on checked-out Sphinx toolchain from svn.python.org anymore

Am 16.02.2014 23:46, schrieb Ned Deily: > In article <3frhkw2rdjz7...@mail.python.org>, > georg.brandl wrote: > >> http://hg.python.org/cpython/rev/eef7899ea7ab >> changeset: 89212:eef7899ea7ab >> user:Georg Brandl >> date:Sun Feb 16 0

Re: [Python-Dev] python 3 niggle: None < 1 raises TypeError

Am 18.02.2014 08:35, schrieb Greg Ewing: > Tim Peters wrote: >> >> [Greg Ewing] >> >>>often >>>one wants to sort a collection of objects having >>>keys that can take on null values. >> >> Perhaps that's often true of your code, but it's never been true of mine. > > It's fairly common in account

Re: [Python-Dev] Python 3.4: Cherry-picking into rc2 and final

Am 19.02.2014 01:07, schrieb Larry Hastings: > On 02/18/2014 03:54 PM, Victor Stinner wrote: >> 2014-02-19 0:46 GMT+01:00 Larry Hastings : >>> Is there *any* reason to make this branch public before 3.4.0 final? >> I'm a little bit worried by the fact that buildbots will not test it. > > "fact"? >

Re: [Python-Dev] Python 3.4: Cherry-picking into rc2 and final

Am 19.02.2014 03:46, schrieb Guido van Rossum: > I do think there's one legitimate concern -- someone might pull a diff from > Larry's branch and then accidentally push it back to the public repo, and then > Larry would be in trouble if he was planning to rebase that diff. (The joys of > DVCS -- we

Re: [Python-Dev] Python 3.4: Cherry-picking into rc2 and final

Am 19.02.2014 00:54, schrieb Barry Warsaw: > On Feb 19, 2014, at 12:38 AM, Matthias Klose wrote: > >>Am 17.02.2014 00:25, schrieb Larry Hastings: >>> And my local branch will remain private until 3.4.0 final ships! >> >>sorry, but this is so wrong. Is there *any* reason why to keep this branch >>p

Re: [Python-Dev] Preview of 3.4 rc2 (so far) is up

Am 19.02.2014 11:04, schrieb Nick Coghlan: > > On 19 Feb 2014 14:05, "Larry Hastings" > wrote: >> >> >> >> The URL has changed slightly. Please go here: >>> >>> http://midwinter.com/~larry/3.4.status/ >> >> You'll notice two things: >> a "merge.status.html" file, which

Re: [Python-Dev] Python 3.4: Cherry-picking into rc2 and final

Am 19.02.2014 16:50, schrieb Guido van Rossum: > On Wed, Feb 19, 2014 at 1:42 AM, Georg Brandl <mailto:g.bra...@gmx.net>> wrote: > > Am 19.02.2014 00:54, schrieb Barry Warsaw: > > On Feb 19, 2014, at 12:38 AM, Matthias Klose wrote: > > > >

Re: [Python-Dev] Python 3.4: Cherry-picking into rc2 and final

Am 19.02.2014 19:00, schrieb Georg Brandl: >> Give Larry some trust and freedom to do things in the way that makes him >> comfortable. > > I have no doubts that Larry will make 3.4 the best Python yet :) So far he > has discussed most of his procedures with us, so I don&

Re: [Python-Dev] Python 3.4: Cherry-picking into rc2 and final

Am 19.02.2014 19:00, schrieb Georg Brandl: > Am 19.02.2014 16:50, schrieb Guido van Rossum: >> On Wed, Feb 19, 2014 at 1:42 AM, Georg Brandl > <mailto:g.bra...@gmx.net>> wrote: >> >> Am 19.02.2014 00:54, schrieb Barry Warsaw: >> > On Feb 1

[Python-Dev] [RELEASED] Python 3.3.5 release candidate 1

nload Python 3.3.5 visit: http://www.python.org/download/releases/3.3.5/ This is a preview release, please report any bugs to http://bugs.python.org/ The final release is scheduled one week from now. Enjoy! - -- Georg Brandl, Release Manager georg at python.org (on behalf of the entire p

Re: [Python-Dev] Poll: Py_REPLACE/Py_ASSIGN/etc

Am 26.02.2014 17:09, schrieb Ryan Gonzalez: > I like Py_DECREF_REPLACE. It gives the impression that it decrefs the original > and replaces it. Agreed, most other suggestions are not really explicit enough. Georg ___ Python-Dev mailing list Python-Dev@

[Python-Dev] [RELEASED] Python 3.3.5 release candidate 2

nload Python 3.3.5 visit: http://www.python.org/download/releases/3.3.5/ This is a preview release, please report any bugs to http://bugs.python.org/ The final release is scheduled one week from now. Enjoy! - -- Georg Brandl, Release Manager georg at python.org (on behalf of the entire p

Re: [Python-Dev] Cherry-pick between Python 3.4 RC2 and final?

Am 03.03.2014 19:31, schrieb Terry Reedy: > On 3/3/2014 7:13 AM, Larry Hastings wrote: >> On 03/03/2014 03:01 AM, Victor Stinner wrote: >>> Hi, >>> >>> I would like to know if the cherry-picking rule still applies for >>> Python 3.4 final? Can I open an issue if I want to see a changeset in >>> the

Re: [Python-Dev] cpython (3.3): Make the various iterators' "setstate" sliently and consistently clip the

Am 06.03.2014 09:02, schrieb Serhiy Storchaka: > 05.03.14 17:24, kristjan.jonsson написав(ла): >> http://hg.python.org/cpython/rev/3b2c28061184 >> changeset: 89477:3b2c28061184 >> branch: 3.3 >> parent: 89475:24d4e52f4f87 >> user:Kristján Valur Jónsson >> date:Wed Mar 0

Re: [Python-Dev] Python 4: don't remove anything, don't break backward compatibility

Am 10.03.2014 23:58, schrieb Allen Li: > I'm not a dev, so my comment doesn't have that much weight, but it is > possible to stop flooding the mailing list with idle chitchat about > something mostly irrelevant and non-productive? > > There's nothing wrong with the current Python versioning scheme

Re: [Python-Dev] undocumented help() function change in Python 3.4?

Am 11.03.2014 06:31, schrieb Ned Deily: > In article > , > Nick Coghlan wrote: >> On 11 March 2014 11:29, R. David Murray wrote: >> > The whatsnew updates (including the one for help) weren't copied into >> > rc3. They will be in final though, unless Larry forgets. >> >> Oh, cool - yes, it wi

Re: [Python-Dev] undocumented help() function change in Python 3.4?

Am 11.03.2014 08:00, schrieb Ned Deily: > In article , > Georg Brandl wrote: > >> Am 11.03.2014 06:31, schrieb Ned Deily: >> > In article >> > , >> > Nick Coghlan wrote: >> >> On 11 March 2014 11:29, R. David Murray wrote: >> &g

Re: [Python-Dev] undocumented help() function change in Python 3.4?

Am 11.03.2014 15:54, schrieb Guido van Rossum: > I'm not sure I agree completely with this lax attitude about the contents of > the > docs, and especially the What's New parts of it (both Misc/NEWS and > Doc/whatsnew/3.4.rst). I don't think anyone here suggested not to update the whatsnew documen

Re: [Python-Dev] Any non-3.4.0 docs in "default"?

Am 13.03.2014 17:50, schrieb Antoine Pitrou: > Le 13/03/2014 17:18, Serhiy Storchaka a écrit : >> 13.03.14 17:16, Larry Hastings написав(ла): >>> I'm strongly considering literally copying over all the content in Doc/ >>> from the default branch to the 3.4 branch. Not cherry-picking doc >>> change

Re: [Python-Dev] Whats New in 3.4 is pretty much done...

Am 13.03.2014 12:34, schrieb Stephen J. Turnbull: > Christian Heimes writes: > > > But I don't want it to sound like an advert... Suggestions? > > Not to worry. It *can't* be an advert -- it's all true, and there are > no irrelevant half-naked glistening bodies. (Former newts in the pond > don

Re: [Python-Dev] cpython: Added Doc/tools/ subdirs to .hgignore.

Am 14.03.2014 16:55, schrieb Benjamin Peterson: > > > On Fri, Mar 14, 2014, at 08:52 AM, Zachary Ware wrote: >> On Fri, Mar 14, 2014 at 10:10 AM, Benjamin Peterson >> wrote: >> > On Fri, Mar 14, 2014, at 07:20 AM, vinay.sajip wrote: >> >> diff --git a/.hgignore b/.hgignore >> >> --- a/.hgignore

[Python-Dev] 3.3 branch is now in security fix mode

Hi all, since 3.3.5 and 3.4.0 practically coincided, it is a good point to end the bugfix maintenance of the 3.3 branch. Please only commit security-related fixes to 3.3 from now -- like for 3.2 -- and as always, please set tracker issues that relate to security fixes to "release blocker" priorit

Re: [Python-Dev] cpython: Add a stub "whatsnew in 3.5" document.

Am 18.03.2014 01:27, schrieb victor.stinner: > http://hg.python.org/cpython/rev/daa6bf71170f > changeset: 89835:daa6bf71170f > user:Victor Stinner > date:Tue Mar 18 00:53:32 2014 +0100 > summary: > Add a stub "whatsnew in 3.5" document. > > files: > Doc/whatsnew/3.5.rst | 1

Re: [Python-Dev] cpython: Add a stub "whatsnew in 3.5" document.

Am 18.03.2014 09:02, schrieb Victor Stinner: > 2014-03-18 7:22 GMT+01:00 Georg Brandl : >> Am 18.03.2014 01:27, schrieb victor.stinner: >>> http://hg.python.org/cpython/rev/daa6bf71170f >>> changeset: 89835:daa6bf71170f >>> user:Victor Stinner >&

Re: [Python-Dev] Poll: Py_REPLACE/Py_ASSIGN/etc

Am 18.03.2014 19:29, schrieb Serhiy Storchaka: > 26.02.14 11:40, Serhiy Storchaka написав(ла): >> Let's choose the least confusing names. >> >> See discussions at: >> >> http://bugs.python.org/issue3081 >> http://bugs.python.org/issue16447 >> http://bugs.python.org/issue20440 >> http://comments.gma

Re: [Python-Dev] unit tests for error messages

Am 19.03.2014 19:55, schrieb Antoine Pitrou: > On Wed, 19 Mar 2014 10:53:31 -0700 > Ethan Furman wrote: > >> I just made a change to some error messages [1] (really, just one): >> >> old behavior: >> >>'%o' % 3.14 >>'float' object cannot be interpreted as an integer >> >> new behavior:

Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements

Am 25.03.2014 08:51, schrieb Nick Coghlan: >> I think that calling it Python 2.8 would be a bad idea for the reasons >> that have already been stated. >> >> Perhaps it should just be called Python 2.7 Enhanced Security ("Python >> 2.7 ES"). > > The PEP currently calls the proposed unmodified fork

Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements

Am 25.03.2014 23:15, schrieb Nick Coghlan: > > On 26 Mar 2014 01:19, "Brett Cannon" > wrote: >> As long as we make it clear we have chosen to change our > backwards-compatibility guarantees in the name of security and have a link to > the last backwards-compatible releas

Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements

Am 26.03.2014 00:06, schrieb Nick Coghlan: > > On 26 Mar 2014 08:32, "Georg Brandl" <mailto:g.bra...@gmx.net>> wrote: >> >> Am 25.03.2014 23:15, schrieb Nick Coghlan: >> > >> > On 26 Mar 2014 01:19, "Brett Cannon" <m

Re: [Python-Dev] PEP 461: Adding % formatting to bytes and bytearray -- Request for Pronouncement

Am 27.03.2014 22:21, schrieb Ethan Furman: > On 03/27/2014 01:44 PM, Guido van Rossum wrote: >> >> Accepted. > > Yay! +1 for that Yay :) Georg ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubs

[Python-Dev] Re: python-iterators mailing list on SourceForge

On 11/05/2021 08:39, Julien Palard via Python-Dev wrote: > Hi, > > PEP 234 mention > https://sourceforge.net/p/python/mailman/python-iterators/ but the > project mailing list archives are marked as "hidden". > > Looks like projects admin and developers can get the "hidden link", but > I think it

Re: [Python-Dev] Python Language Summit at PyCon: Agenda

Am 27.02.2013 17:51, schrieb Michael Foord: > Hello all, > > PyCon, and the Python Language Summit, is nearly upon us. We have a good > number of people confirmed to attend. If you are intending to come to the > language summit but haven't let me know please do so. > > The agenda of topics for

Re: [Python-Dev] Difference in RE between 3.2 and 3.3 (or Aaron Swartz memorial)

Am 07.03.2013 11:08, schrieb Matej Cepl: >> Anyway, you spotted a missed optimization: it's now "fixed" in >> Python 3.3 and 3.4 by the following commits. > > Well, whatever is the problem, it is not fixed in python 3.3.0 > (as you can see in > https://travis-ci.org/mcepl/html2text/builds/4969045

Re: [Python-Dev] IDLE in the stdlib

Am 21.03.2013 00:47, schrieb Barry Warsaw: > On Mar 20, 2013, at 11:11 PM, Antoine Pitrou wrote: > >>On Wed, 20 Mar 2013 15:05:40 -0700 >>Nick Coghlan wrote: >>> >>> Yes, the status quo of Idle is not something we should allow to >>> continue indefinitely, but decisions about its future developm

Re: [Python-Dev] How to fix the incorrect shared library extension on linux for 3.2 and newer?

Am 20.03.2013 22:36, schrieb Barry Warsaw: > On Mar 20, 2013, at 01:18 PM, Matthias Klose wrote: > >>The patch in the issue now makes a distinction between EXT_SUFFIX and >>SHLIB_SUFFIX, and restores the value of SO to SHLIB_SUFFIX. Now this could >>break users of sysconfig.get_config_var('SO'),

Re: [Python-Dev] IDLE in the stdlib

Am 21.03.2013 16:23, schrieb Nick Coghlan: > On Thu, Mar 21, 2013 at 6:22 AM, Barry Warsaw wrote: >> On Mar 21, 2013, at 05:25 AM, Eli Bendersky wrote: >> >>>1. Whether IDLE should be developed separately from the core Python >>>repository (while still being shipped). >>> >>>I really want to const

Re: [Python-Dev] IDLE in the stdlib

Am 21.03.2013 19:13, schrieb Antoine Pitrou: > On Wed, 20 Mar 2013 19:57:54 -0700 > Raymond Hettinger wrote: >> >> On Mar 20, 2013, at 12:38 PM, Barry Warsaw wrote: >> >> > Right. Ultimately, I think IDLE should be a separate project entirely, >> > but I >> > guess there's push back against t

Re: [Python-Dev] IDLE in the stdlib

Am 22.03.2013 10:48, schrieb Antoine Pitrou: > Le Thu, 21 Mar 2013 21:38:41 +0100, > Georg Brandl a écrit : > >> Am 21.03.2013 19:13, schrieb Antoine Pitrou: >> > On Wed, 20 Mar 2013 19:57:54 -0700 >> > Raymond Hettinger wrote: >> >> >

[Python-Dev] [RELEASED] Python 3.2.4 rc 1 and Python 3.3.1 rc 1

notice to: http://bugs.python.org/ To download Python 3.2.4 or Python 3.3.1, visit: http://www.python.org/download/releases/3.2.4/ or http://www.python.org/download/releases/3.3.1/ respectively. Enjoy! - -- Georg Brandl, Release Manager georg at python.org (on behalf of the entire

Re: [Python-Dev] [RELEASE] Python 2.7.4 release candidate 1

Am 26.03.2013 13:13, schrieb Benjamin Peterson: > 2013/3/26 Matthias Klose : >> Am 25.03.2013 01:30, schrieb Benjamin Peterson: >>> 2.7.4 will be the latest maintenance release in the Python 2.7 series. >> >> I hope it's not (and in the IDLE thread you say so otherwise too). > > "latest" is differ

Re: [Python-Dev] Semantics of __int__(), __index__()

Am 04.04.2013 16:47, schrieb Chris Angelico: > On Fri, Apr 5, 2013 at 1:23 AM, Oscar Benjamin > wrote: >> The reason for calling int(obj) is to get an object that is precisely >> of type int. When I call this I do not want any modified or additional >> methods or data attached to the resulting obj

Re: [Python-Dev] give IDLE its own NEWS section?

Am 06.04.2013 16:58, schrieb Benjamin Peterson: > I noticed IDLE changes were being put under the "library" section in > Misc/NEWS. How about creating a IDLE section? There is also Lib/idlelib/NEWS.txt. It also contains IDLE news items and is shown in a dialog box from within IDLE. IMO it's fine

[Python-Dev] [RELEASED] Python 3.2.4 and Python 3.3.1

://www.python.org/download/releases/3.3.1/ respectively. As always, please report bugs to http://bugs.python.org/ Enjoy! - -- Georg Brandl, Release Manager georg at python.org (on behalf of the entire python-dev team and all contributors) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU

Re: [Python-Dev] The end of 2.7

Am 06.04.2013 23:02, schrieb Benjamin Peterson: > Per my last message, 2.7.4 has at long last been released. I apologize > for the long interval between 2.7.3 and 2.7.4. To create more > determinism in the future, I will be soon updating PEP 373 with > approximate dates of future 2.7 bugfix release

Re: [Python-Dev] The end of 2.7

Am 07.04.2013 14:10, schrieb Skip Montanaro: > I started writing this last night before the flurry of messages which > arrived overnight. I thought originally, "Oh, Skip, you're being too > harsh." But now I'm not so sure. I think you are approaching the > issue of 2.7's EOL incorrectly. Of thos

Re: [Python-Dev] A decade as a core dev

Am 18.04.2013 17:02, schrieb Brett Cannon: > Today marks my 10 year anniversary as a core developer on Python. I > wrote a blog post to mark the occasion > (http://sayspy.blogspot.ca/2013/04/a-decade-of-commits.html), but I > wanted to personally thank python-dev for the past decade (and > whatever

[Python-Dev] enum discussion: can someone please summarize open issues?

Hi all, I've just read a few dozen enum-related emails, and there are so many more. I would like to form an opinion about the proposal(s), but I feel I don't know what the actual issues are anymore. In the past, somebody usually presented a summary of the issues so far, and that was a good point

Re: [Python-Dev] enum discussion: can someone please summarize open issues?

Am 28.04.2013 22:36, schrieb Ethan Furman: >>> Example enumeration: >>> >>> class Seasons(Enum): SPRING = 1 SUMMER = 2 AUTUMN = 3 WINTER = 4 >>> >>> days_in_year = 365 >>> >>> @property def avg_temp(self): return (75, 92, 66, 33)[int(self)+1] # >>> enums are 1-based >>> >>> >>> Definite Issue

[Python-Dev] Regression fix releases coming

Hi all, since there turned out to be a "critical mass" of regressions in 2.7.4/ 3.2.4/3.3.1, Benjamin and I would like to release a releasing fixing these next weekend. Since we would like to cherry-pick only regression fixes into these releases, please make sure any regression issues you know of

Re: [Python-Dev] PEP-435 reference implementation

Am 01.05.2013 17:35, schrieb Steven D'Aprano: > On 02/05/13 01:09, Ethan Furman wrote: >> New repo to avoid confusion: >> >> https://bitbucket.org/stoneleaf/ref435 > > Apparently I have to log in before I can even see the repo. > > Not going to happen. I'm sure he made the repo private by accide

Re: [Python-Dev] PEP-435 reference implementation

Am 01.05.2013 17:09, schrieb Ethan Furman: > New repo to avoid confusion: > > https://bitbucket.org/stoneleaf/ref435 > > which has the latest updates from the feedback. > > Subclassing is again disabled. Let's get the rest of it done, then we can > come back to that issue if necessary. Thanks.

Re: [Python-Dev] Enum: subclassing?

Am 01.05.2013 20:04, schrieb Eli Bendersky: > Actually, in flufl.enum, IntEnum had to define a magic __value_factory__ > attribute, but in the current ref435 implementation this isn't needed, so > IntEnum is just: > > class IntEnum(int, Enum): > ''' > Class where every instance is a subcl

Re: [Python-Dev] Enum: subclassing?

Am 01.05.2013 20:44, schrieb Antoine Pitrou: > On Wed, 01 May 2013 10:21:30 -0700 > Ethan Furman wrote: >> We may not want to /completely/ disallow subclassing. Consider: >> >> --> class StrEnum(str, Enum): >> ...'''string enums for Business Basic variable names''' >> ... >> --> class Vendor

Re: [Python-Dev] Enum: subclassing?

Am 01.05.2013 22:05, schrieb Eli Bendersky: > > > > On Wed, May 1, 2013 at 11:59 AM, Georg Brandl <mailto:g.bra...@gmx.net>> wrote: > > Am 01.05.2013 20:44, schrieb Antoine Pitrou: > > On Wed, 01 May 2013 10:21:30 -0700 > > Ethan F

Re: [Python-Dev] Enum: subclassing?

Am 01.05.2013 22:09, schrieb Eli Bendersky: > > > > On Wed, May 1, 2013 at 11:47 AM, Georg Brandl <mailto:g.bra...@gmx.net>> wrote: > > Am 01.05.2013 20:04, schrieb Eli Bendersky: > > > Actually, in flufl.enum, IntEnum had to define a magic __value

Re: [Python-Dev] Enum: subclassing?

Am 01.05.2013 23:19, schrieb Eli Bendersky: > It's a common pattern to do this with a base class rather than a > mixin, though, and I think the rule "only allow subclassing empty > enums" makes a lot of sense. > > > I see your point (and Antoine's example in the next email is good),

Re: [Python-Dev] Enum: subclassing?

Am 01.05.2013 23:48, schrieb Eli Bendersky: > Well, my point is that you currently don't have to inherit from int (or > IntEnum) > to get an __int__ method on your Enum, which is what I find questionable. > IMO > conversion to integers should only be defined for IntEnums. (But I >

Re: [Python-Dev] Enum: subclassing?

Am 01.05.2013 23:44, schrieb Georg Brandl: > Traceback (most recent call last): > File "/home/gbr/devel/ref435/ref435.py", line 84, in __new__ > enum_item = obj_type.__new__(result, value) > TypeError: object.__new__(SIPStatusCode) is not safe, use int.__new__() >

Re: [Python-Dev] PyPy, Jython, & IronPython: Enum convenience function and pickleablity

Am 02.05.2013 22:10, schrieb Antoine Pitrou: > On Thu, 2 May 2013 15:48:14 -0400 > Benjamin Peterson wrote: >> 2013/5/2 Ethan Furman : >> > In order for the Enum convenience function to be pickleable, we have this >> > line of code in the metaclass: >> > >> > enum_class.__module__ = sys._getfr

Re: [Python-Dev] PyPy, Jython, & IronPython: Enum convenience function and pickleablity

Am 02.05.2013 23:57, schrieb Eli Bendersky: >> Eli, it would be nice if you stopped with this claim. > > > I'm not advocating "not having a convenience syntax", I'm advocating > having a convenience syntax which is *class-based* rather than > function-based. > > Debuggers are bes

Re: [Python-Dev] PyPy, Jython, & IronPython: Enum convenience function and pickleablity

Am 03.05.2013 11:40, schrieb Steven D'Aprano: > On 03/05/13 18:42, Antoine Pitrou wrote: >> Le Fri, 3 May 2013 09:14:22 +1000, Nick Coghlan a >> écrit : > >>> I would suggest moving the field names into the class header for a class >>> based convenience API: >>> >>> class Animal(Enum, members='c

Re: [Python-Dev] enum discussion: can someone please summarize open issues?

Am 04.05.2013 01:22, schrieb Antoine Pitrou: > On Sat, 04 May 2013 11:15:17 +1200 > Greg Ewing wrote: >> Eli Bendersky wrote: >> > I'm just curious what it is about enums that sets everyone on a "let's >> > make things safer" path. Python is about duck typing, it's absolutely >> > "unsafe" in th

Re: [Python-Dev] PEP 435: initial values must be specified? Yes

Am 05.05.2013 22:09, schrieb Ethan Furman: > About the closest you going to be able to get is something like: > > def e(_next=[1]): > e, _next[0] = _next[0], _next[0] + 1 > return e > > class Color(Enum): > red = e() > green = e() > blue = e() Uh, that's surely more nic

Re: [Python-Dev] 2.7.5 baking

Am 12.05.2013 06:03, schrieb Benjamin Peterson: > The long anticipated "emergency" 2.7.5 release has now been tagged. It > will be publicly announced as binaries arrive. > > Originally, I was just going to cherrypick regression fixes onto the > 2.7.4 release and release those as 2.7.5. I started t

Re: [Python-Dev] 2.7.5 baking

Am 15.05.2013 09:55, schrieb M.-A. Lemburg: > On 12.05.2013 06:03, Benjamin Peterson wrote: >> The long anticipated "emergency" 2.7.5 release has now been tagged. It >> will be publicly announced as binaries arrive. >> >> Originally, I was just going to cherrypick regression fixes onto the >> 2.7.

[Python-Dev] [RELEASED] Python 3.2.5 and Python 3.3.2

report bugs to http://bugs.python.org/ (Thank you to those who reported these regressions.) Enjoy! - -- Georg Brandl, Release Manager georg at python.org (on behalf of the entire python-dev team and all contributors) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux

Re: [Python-Dev] [RELEASED] Python 3.2.5 and Python 3.3.2

Am 18.05.2013 05:21, schrieb Nick Coghlan: > On Sat, May 18, 2013 at 7:59 AM, Antoine Pitrou wrote: >> On Thu, 16 May 2013 13:24:36 +0200 >> Charles-François Natali wrote: >>> 2013/5/16 Serhiy Storchaka : >>> > 16.05.13 08:20, Georg Brandl написав(ла): &

Re: [Python-Dev] PEP 409 and the stdlib

Am 20.05.2013 17:39, schrieb Steven D'Aprano: > On 21/05/13 00:12, Ethan Furman wrote: > > >> As a case in point, base64.py is currently getting a bug fix, and also >> contains this code: >> >> def b32decode(s, casefold=False, map01=None): . . . for i in range(0, >> len(s), 8): quanta = s[i: i +

Re: [Python-Dev] End of the mystery "@README.txt Mercurial bug"

Am 26.06.2013 16:24, schrieb Victor Stinner: > 2013/6/26 Eric V. Smith : >> I think that's exactly what's happening. >> >> From the bug report: >> >> find $(srcdir) '(' -name '*.fdc' -o -name '*~' \ >>-o -name '[@,#]*' -o -name '*.old' \ >>

Re: [Python-Dev] End of the mystery "@README.txt Mercurial bug"

Am 01.07.2013 23:05, schrieb Victor Stinner: > Hi Georg, > > 2013/7/1 Georg Brandl : >> Am 26.06.2013 16:24, schrieb Victor Stinner: >>> 2013/6/26 Eric V. Smith : >>>> I think that's exactly what's happening. >>>> >>>> From

Re: [Python-Dev] Status of 3.2 in Hg repository?

Am 21.08.2013 21:26, schrieb Brett Cannon: > > > > On Wed, Aug 21, 2013 at 2:22 PM, Tim Peters > wrote: > > [Tim, wondering why the 3.2 branch isn't "inactive"] > >> ... > >> So let's try a different question ;-) Would anyone _object_ to > >> compl

Re: [Python-Dev] Status of 3.2 in Hg repository?

Am 24.08.2013 22:38, schrieb Tim Peters: > [Tim, wondering why the 3.2 branch isn't "inactive"] > > [Georg Brandl] >> FWIW I have no real objections, I just don't see the gain. > > I'm glad it's OK! Especially because it's already been d

Re: [Python-Dev] PEP 455: TransformDict

On 09/13/2013 11:45 PM, Antoine Pitrou wrote: > On Fri, 13 Sep 2013 23:18:39 +0300 > Serhiy Storchaka wrote: >> 13.09.13 23:02, Antoine Pitrou написав(ла): >> > On Fri, 13 Sep 2013 16:54:01 -0300 >> > "Joao S. O. Bueno" wrote: >> >> I see the PEP does not contemplate a way to retrieve the origina

Re: [Python-Dev] PEP 455: TransformDict

On 09/13/2013 10:09 PM, R. David Murray wrote: > On Fri, 13 Sep 2013 20:40:58 +0200, Antoine Pitrou > wrote: >> Rationale >> = >> >> Numerous specialized versions of this pattern exist. The most common >> is a case-insensitive case-preserving dict, i.e. a dict-like container >> which ma

Re: [Python-Dev] PEP 455: TransformDict

On 09/13/2013 08:40 PM, Antoine Pitrou wrote: > > Hello, > > Following the python-dev discussion, I've written a PEP to recap the > proposal and the various arguments. It's inlined below, and it will > probably appear soon at http://www.python.org/dev/peps/pep-0455/, too. > Looks good to me. G

Re: [Python-Dev] cpython: Issue #18571: Implementation of the PEP 446: file descriptors and file handles

On 08/28/2013 01:20 AM, victor.stinner wrote: > http://hg.python.org/cpython/rev/ef889c3d5dc6 > changeset: 85420:ef889c3d5dc6 > user:Victor Stinner > date:Wed Aug 28 00:53:59 2013 +0200 > summary: > Issue #18571: Implementation of the PEP 446: file descriptors and file > handl

Re: [Python-Dev] License() release list is imcomplete; intentional?

On 09/17/2013 05:37 PM, Terry Reedy wrote: > On 2.7, >>> license() return a text that includes a complete list of > releases from 1.6 to 2.7 and stops there > Release Derived YearOwner GPL- > fromcompatible? (1) >

Re: [Python-Dev] License() release list is imcomplete; intentional?

Now tracked at http://bugs.python.org/issue19043 Georg On 09/18/2013 04:57 PM, Guido van Rossum wrote: > OK. Let's do it. > > > On Wed, Sep 18, 2013 at 1:54 AM, Georg Brandl <mailto:g.bra...@gmx.net>> wrote: > > On 09/17/2013 05:37 PM, Terry Reedy wr

Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message

On 09/22/2013 10:19 AM, Antoine Pitrou wrote: > On Sat, 21 Sep 2013 19:55:05 -0400 > Terry Reedy wrote: >> >> > In the general case it represents a bug in >> > the code that should be fixed. Most such errors arise from the vagaries >> > of module finalization (such as your issue 19021), >> >> L

Re: [Python-Dev] Best practice for documentation for std lib

On 09/22/2013 05:13 AM, Steven D'Aprano wrote: > Hi all, > > I have a question about how I should manage documentation for the > statistics module for Python 3.4. At the moment, I have extensive > docstrings in the module itself. I don't believe anyone has flagged that > as "too much informatio

Re: [Python-Dev] Best practice for documentation for std lib

On 09/22/2013 12:16 PM, Nick Coghlan wrote: > On 22 September 2013 18:54, Georg Brandl wrote: >> I don't really buy the argument "but then there is no complete documentation >> set in the checkout" -- who reads that in preference to docs.python.org? >> And

Re: [Python-Dev] Best practice for documentation for std lib

On 09/22/2013 02:54 PM, Eli Bendersky wrote: > > > > On Sat, Sep 21, 2013 at 8:13 PM, Steven D'Aprano > wrote: > > Hi all, > > I have a question about how I should manage documentation for the > statistics module for Python 3.4. At the moment, I have ex

Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message

Am 24.09.2013 00:11, schrieb Greg Ewing: > Antoine Pitrou wrote: >> Yes, but I agree with Greg that "unraisable" is wrong. After all, it >> was raised, and it can even be caught by the programmer (inside >> __del__). > > How about something like "Uncaught exception in __del__ > method ignored"? It

Re: [Python-Dev] Best practice for documentation for std lib

Am 23.09.2013 00:03, schrieb Guido van Rossum: > AFAIU, the proposal is to embed parts of the concise docstring into the > more > verbose .rst documentation. > > > I still think that's a bad idea. Someone editing the docstring may introduce a > terminology change or some other style/gra

Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message

Am 26.09.2013 08:22, schrieb Nick Coghlan: > On 26 September 2013 15:42, Armin Rigo wrote: >> Hi Nick, >> >> On Thu, Sep 26, 2013 at 6:59 AM, Nick Coghlan wrote: I'm strongly in favour of Georg's one ("Exception in __del__ caught and not propagated"). >>> >>> Such a change is highly un

Re: [Python-Dev] cpython: Don't use fancy new Python features like 'with' - some bots don't have them

Am 26.09.2013 15:42, schrieb eli.bendersky: > http://hg.python.org/cpython/rev/931d95e9067f > changeset: 85801:931d95e9067f > user:Eli Bendersky > date:Thu Sep 26 06:41:36 2013 -0700 > summary: > Don't use fancy new Python features like 'with' - some bots don't have them > and

Re: [Python-Dev] cpython: Use cached builtins.

Am 02.10.2013 21:58, schrieb Victor Stinner: > I don't remember where, but I remember that I also saw things like > "str=str, len=len, ...". So you keep the same name, but you use fast > local lookups instead of slow builtin lookups. In this case they aren't even fast local lookups but (slightly)

Re: [Python-Dev] Optimization

Am 05.10.2013 21:42, schrieb Serhiy Storchaka: > Please remember me, what was common decision about CPython-only > optimizations which change computation complexity? I.g. constant > amortization time of += for byte objects and strings, or linear time of > sum() for sequences? This appears to be

Re: [Python-Dev] Optimization

Am 06.10.2013 01:37, schrieb Antoine Pitrou: > On Sun, 6 Oct 2013 09:32:30 +1000 > Nick Coghlan wrote: >> On 6 Oct 2013 08:59, "Antoine Pitrou" wrote: >> > >> > On Sat, 5 Oct 2013 15:35:30 -0700 >> > Raymond Hettinger wrote: >> > > >> > > Making bytearray's efficiently pop from the left side is

Re: [Python-Dev] Reduce memory footprint of Python

Am 06.10.2013 17:32, schrieb Victor Stinner: > Hi, > > Slowly, I'm trying to see if it would be possible to reduce the memory > footprint of Python using the tracemalloc module. > > First, I noticed that linecache can allocate more than 2 MB. What do > you think of adding a registry of "clear cac

Re: [Python-Dev] PEP 457: Syntax For Positional-Only Parameters

Am 09.10.2013 01:33, schrieb Larry Hastings: > > I've contributed a new PEP to humanity. I include the RST for your reading > pleasure below, but you can also read it online here: > > http://www.python.org/dev/peps/pep-0457/ ... >* Documentation can clearly, unambiguously, and > c

Re: [Python-Dev] PEP 457: Syntax For Positional-Only Parameters

Am 09.10.2013 15:32, schrieb Larry Hastings: > On 10/09/2013 02:38 PM, Benjamin Peterson wrote: >> Why does a syntax need to be reserved? Documentation conventions and >> the syntax of internal tools like argument clinic may be changed any >> time we like. > > If Argument Clinic is accepted, and s

Re: [Python-Dev] PEP 457: Syntax For Positional-Only Parameters

Am 09.10.2013 15:56, schrieb Larry Hastings: > On 10/09/2013 07:15 AM, Georg Brandl wrote: >> We have quite a large >> amount of C functions with positional-only parameters. Adding a "/" >> to each of those is a) a tedious task and b) probably not helpful for >&

<    1   2   3   4   5   6   7   8   9   10   >