[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] Current Python 3.2 status?

On 06/11/2016 07:41 PM, Chi Hsuan Yen wrote: > > > On Sun, Jun 12, 2016 at 1:02 AM, Berker Peksağ > wrote: > > On Sat, Jun 11, 2016 at 8:59 AM, Chi Hsuan Yen > wrote: > > Hello all, > > > > Georg said in February th

Re: [Python-Dev] Removing the provisional label from pathlib

ches, that's why I > wrote this table ;-) > https://docs.python.org/devguide/#status-of-python-branches > > By the way, is it still up to date? Python 3.2 end-of-line is > documented as 2016-02-20, so its status should be end-of-life, no? > > Georg Brandl scheduled a 3.2.7

Re: [Python-Dev] PEP 515: Underscores in Numeric Literals (revision 3)

I'm happy with the latest version. Georg On 05/11/2016 06:46 PM, Guido van Rossum wrote: > If the authors are happy I'll accept it right away. > > (I vaguely recall there's another PEP that's ready for pronouncement -- but > which one?) > > On Wed, May 11, 2016 at 9:34 AM, Brett Cannon

Re: [Python-Dev] Defining a path protocol

On 04/06/2016 07:26 PM, Brett Cannon wrote: > WIth Ethan volunteering to do the work to help make a path protocol a thing -- > and I'm willing to help along with propagating this through the stdlib where I > think Serhiy might be interested in helping as well -- and a seeming consensus > this is a

Re: [Python-Dev] PEP 515: Underscores in Numeric Literals (revision 3)

e? >> >> On Sat, 13 Feb 2016 at 00:49 Georg Brandl wrote: >>> >>> Hi all, >>> >>> after talking to Guido and Serhiy we present the next revision >>> of this PEP. It is a compromise that we are all happy with, >>> and a relatively res

Re: [Python-Dev] Very old git mirror under github user "python-git"

On 02/27/2016 11:45 PM, Matthias Bussonnier wrote: > Hi all, > > >> On Feb 27, 2016, at 14:21, Alexander Walters > > wrote: >> >> Can we even ask github to pull it down and reasonably expect them to comply? >> Their entire model is built on everyone forking every

Re: [Python-Dev] Python 3.2.7 and 3.3.7

On 02/11/2016 06:34 PM, Georg Brandl wrote: > Hi all, > > I'm planning to release 3.2.7 and 3.3.7 at the end of February. > There will be a release candidate on Feb 20, and the final on > Feb 27, if there is no holdup. > > These are both security (source-only) releases.

Re: [Python-Dev] PEP 515: Underscores in Numeric Literals (revision 3)

On 02/13/2016 12:10 PM, Serhiy Storchaka wrote: > On 13.02.16 10:48, Georg Brandl wrote: >> Following the same rules for placement, underscores will be allowed in >> the following constructors: >> >> - ``int()`` (with any base) >> - ``float()`` >> - ``complex

[Python-Dev] PEP 515: Underscores in Numeric Literals (revision 3)

- PEP: 515 Title: Underscores in Numeric Literals Version: $Revision$ Last-Modified: $Date$ Author: Georg Brandl, Serhiy Storchaka Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 10-Feb-2016 Python-Version: 3.6 Post-History: 10-Feb-2016, 11-Feb-2016 Abstract and

Re: [Python-Dev] Py_SETREF again

On 02/12/2016 10:45 AM, Serhiy Storchaka wrote: > Sorry to bringing this up again. I was hoping we were done with that. > > When discussing the name of the Py_SETREF macro I was supposed to add a > pair of macros: for Py_DECREF and Py_XDECREF. But I got a lot of > opinions to be limited to only

Re: [Python-Dev] PEP 515: Underscores in Numeric Literals

On 02/11/2016 06:19 PM, Serhiy Storchaka wrote: >> Thanks for the alternate patch. I used the two-function approach you took >> in ast.c for my latest revision. >> >> I still think that some cases (like two of the examples in the PEP, >> 0b__ and 1.5_j) are worth having, and therefore a m

[Python-Dev] Python 3.2.7 and 3.3.7

Hi all, I'm planning to release 3.2.7 and 3.3.7 at the end of February. There will be a release candidate on Feb 20, and the final on Feb 27, if there is no holdup. These are both security (source-only) releases. 3.2.7 will be the last release from the 3.2 series. If you know of any patches tha

Re: [Python-Dev] PEP 515: Underscores in Numeric Literals

On 02/11/2016 05:52 PM, Steve Dower wrote: > On 11Feb2016 0651, Barry Warsaw wrote: >> On Feb 11, 2016, at 09:22 AM, Georg Brandl wrote: >> >>> based on the feedback so far, I revised the PEP. There is now >>> a much simpler rule for allowed underscores, with

Re: [Python-Dev] PEP 515: Underscores in Numeric Literals

On 02/11/2016 11:17 AM, Serhiy Storchaka wrote: >> **Group 3: only between digits, only one underscore** >> >> * Ada [8]_ >> * Julia (but not in the exponent part of floats) [9]_ >> * Ruby (docs say "anywhere", in reality only between digits) [10]_ > > C++ is in this group too. > > The documenta

Re: [Python-Dev] PEP 515: Underscores in Numeric Literals

On 02/11/2016 10:10 AM, Paul Moore wrote: > On 10 February 2016 at 23:14, Steven D'Aprano wrote: >> On Wed, Feb 10, 2016 at 10:53:09PM +, Paul Moore wrote: >>> On 10 February 2016 at 22:20, Georg Brandl wrote: >>> > This came up in python-ideas, a

[Python-Dev] PEP 515: Underscores in Numeric Literals

Literals Version: $Revision$ Last-Modified: $Date$ Author: Georg Brandl Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 10-Feb-2016 Python-Version: 3.6 Abstract and Rationale == This PEP proposes to extend Python's syntax so that underscores can be us

Re: [Python-Dev] PEP 515: Underscores in Numeric Literals

On 02/11/2016 12:04 AM, Victor Stinner wrote: > It looks like the implementation https://bugs.python.org/issue26331 > only changes the Python parser. > > What about other functions converting strings to numbers at runtime > like int(str) and float(str)? Paul also asked for Decimal(str). I added t

Re: [Python-Dev] PEP 515: Underscores in Numeric Literals

On 02/10/2016 11:42 PM, Glenn Linderman wrote: > On 2/10/2016 2:20 PM, Georg Brandl wrote: >> This came up in python-ideas, and has met mostly positive comments, >> although the exact syntax rules are up for discussion. >>

Re: [Python-Dev] PEP 515: Underscores in Numeric Literals

On 02/10/2016 11:35 PM, Brett Cannon wrote: >> Examples:: >> >> # grouping decimal numbers by thousands >> amount = 10_000_000.0 >> >> # grouping hexadecimal addresses by words >> addr = 0xDEAD_BEEF >> >> # grouping bits into bytes in a binary literal

Re: [Python-Dev] PEP 515: Underscores in Numeric Literals

On 02/11/2016 12:45 AM, Andrew Barnert via Python-Dev wrote: > On Feb 10, 2016, at 14:20, Georg Brandl wrote: > > First, general questions: should the PEP mention the Decimal constructor? > What about int and float (I'd assume int(s) continues to work as always, > while in

Re: [Python-Dev] PEP 515: Underscores in Numeric Literals

On 02/11/2016 02:16 AM, Martin Panter wrote: > I have occasionally wondered about this missing feature. > > On 10 February 2016 at 22:20, Georg Brandl wrote: >> Abstract and Rationale >> == >> >> This PEP proposes to extend Python's

[Python-Dev] PEP 515: Underscores in Numeric Literals

-Modified: $Date$ Author: Georg Brandl Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 10-Feb-2016 Python-Version: 3.6 Abstract and Rationale == This PEP proposes to extend Python's syntax so that underscores can be used in integral and floating-point n

Re: [Python-Dev] Issue #26204: compiler now emits a SyntaxWarning on constant statement

On 02/09/2016 10:57 AM, Joseph Martinot-Lagarde wrote: > Victor Stinner gmail.com> writes: > >> >> Hi, >> >> I changed the Python compiler to ignore any kind "constant >> expressions", whereas it only ignored strings and integers before: >> http://bugs.python.org/issue26204 >> >> The compiler

Re: [Python-Dev] Update PEP 7 to require curly braces in C

On 01/19/2016 01:18 AM, Terry Reedy wrote: > Though I don't write C anymore, I occasionally read our C sources. I > dislike mixed bracketing in a multiple clause if/else statement, and > would strongly recommend against that. On the other hand, to my > Python-trained eye, brackets for one li

Re: [Python-Dev] Update PEP 7 to require curly braces in C

On 01/17/2016 11:19 PM, Brett Cannon wrote: > > > On Sun, 17 Jan 2016, 13:59 Ethan Furman > wrote: > > On 01/17/2016 11:10 AM, Brett Cannon wrote: > > > https://www.imperialviolet.org/2014/02/22/applebug.html. Skipping the > > curly braces is purely an ae

Re: [Python-Dev] doc tests failing

On 11/13/2015 04:12 PM, Ethan Furman wrote: > What am I doing wrong? Running "make doctest" in the first place. The doctests in the core docs were not written to support that, and also never updated to do so. Georg > I have tried: > > > h

Re: [Python-Dev] PEP: Collecting information about git

e been a (moderate) advocate for switching to git and > GitHub. > > On Tue, Sep 15, 2015 at 11:19 AM, Georg Brandl <mailto:g.bra...@gmx.net>> wrote: > > On 09/15/2015 08:02 PM, Oleg Broytman wrote: > > On Tue, Sep 15, 2015 at 09:46:55AM -0700, Benjami

Re: [Python-Dev] PEP: Collecting information about git

On 09/15/2015 08:02 PM, Oleg Broytman wrote: > On Tue, Sep 15, 2015 at 09:46:55AM -0700, Benjamin Peterson > wrote: >> This looks like good information, but why is it a PEP? If anything, the >> devguide was probably be more appropriate. But even that's strange >> considering we don't use git at t

Re: [Python-Dev] How far to go with user-friendliness

On 07/14/2015 02:39 PM, Nick Coghlan wrote: > Drawing the line at only rejecting "assert_" *would* have been a > reasonable alternative design choice, but it isn't the one Kushal and > Michael made, and there isn't a compelling argument in favour of > changing the implementation of the new guard t

Re: [Python-Dev] subclassing builtin data structures

On 02/14/2015 07:26 PM, Alexander Belopolsky wrote: > In the case of int, there is a good reason for this behavior - bool. In > python, > we want True + True == 2. In numpy, where binary operations preserve > subclasses, you have > import numpy numpy.bool_(1) + numpy.bool_(1) > True

Re: [Python-Dev] (no subject)

On 02/10/2015 10:33 AM, Paul Moore wrote: > On 10 February 2015 at 00:29, Neil Girdhar wrote: >>> > function(**kw_arguments, **more_arguments) >>> If the key "key1" is in both dictionaries, more_arguments wins, right? >> >> >> There was some debate and it was decided that duplicate keyword argumen

Re: [Python-Dev] PEP 475 accepted

On 02/03/2015 04:25 PM, Larry Hastings wrote: > > On 02/02/2015 12:58 PM, Victor Stinner wrote: >> 2015-02-02 21:49 GMT+01:00 Guido van Rossum : >>> W00t! Congratulations les Français! >> We will celebrate this acceptance with a glass of red wine and cheese. > > If it were me, I'd use separate gl

Re: [Python-Dev] Any grammar experts?

On 01/26/2015 07:25 PM, Skip Montanaro wrote: > On Mon, Jan 26, 2015 at 12:12 PM, Antoine Pitrou wrote: >> I also think the multiple-starargs function calls are completely >> overboard: >> >> f(**someargs, **someotherargs) >> >> (I might add I've never felt any need for those) > > This makes se

Re: [Python-Dev] Python bug tracker & Roundup

On 01/26/2015 09:25 PM, Ethan Furman wrote: > Do we have our own mailing list for Roundup? > > I'm trying to fix the Activity Date search bug (only returns issues where the > *last* activity was on a date, not *any* activity on a date). That would be tracker-discuss. Georg _

Re: [Python-Dev] Any grammar experts?

On 01/25/2015 04:08 PM, Antoine Pitrou wrote: > On Sat, 24 Jan 2015 21:10:51 -0500 > Neil Girdhar wrote: >> To finish PEP 448, I need to update the grammar for syntax such as >> >> {**x for x in it} > > Is this seriously allowed by the PEP? What does it mean exactly? It appears to go a bit far.

Re: [Python-Dev] C ABI and #ifndef Py_LIMITED_API

On 01/14/2015 08:32 AM, Ethan Furman wrote: > In the CPython source code I see > > #ifndef Py_LIMITED_API > > Is there a section in the docs that explains the purpose? If not, can > someone give me the cliff notes version? PEP 384, and in particular [1] should get you started. cheers, Georg [

Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github

On 12/01/2014 01:05 PM, Matěj Cepl wrote: > On 2014-12-01, 07:43 GMT, Donald Stufft wrote: >>> I do not choose tools simply because they are written in >>> Python -- I choose them because, being written in Python, I >>> I can work on them if I need to: I can enhance them, I can >>> fix them, I ca

Re: [Python-Dev] Move selected documentation repos to PSF BitBucket account?

On 11/24/2014 12:21 AM, Brett Cannon wrote: > > > On Sun Nov 23 2014 at 4:18:37 PM Georg Brandl <mailto:g.bra...@gmx.net>> wrote: > > On 11/23/2014 09:42 PM, Brett Cannon wrote: > > > [SNIP] > > > > And I'm still in support n

Re: [Python-Dev] Move selected documentation repos to PSF BitBucket account?

On 11/23/2014 09:42 PM, Brett Cannon wrote: > The more problematic category are pre-push hooks. We use them for > checking > and rejecting commits with > > * disallowed branches > * non-conformant whitespace > * wrong EOL style > * multiple heads per named branch > >

Re: [Python-Dev] Move selected documentation repos to PSF BitBucket account?

On 11/23/2014 09:38 PM, Donald Stufft wrote: > >> On Nov 23, 2014, at 3:03 PM, Georg Brandl wrote: >> >> The next point is that there is no easy way to change the target branch of >> a pull request (on github or bitbucket). People will usually make patches >>

Re: [Python-Dev] Move selected documentation repos to PSF BitBucket account?

On 11/23/2014 07:03 PM, Ryan wrote: > I can agree with most of these points. Some more things to consider: > > - Git is 20x faster than Hg (that's 99% of the reason I switched and hate > using > Darcs) You won't get much traction with this argument around here. As long as there aren't specific

Re: [Python-Dev] Move selected documentation repos to PSF BitBucket account?

On 11/23/2014 05:55 PM, Brett Cannon wrote: > I guess my question is who and what is going to be disrupted if we go with > Guido's suggestion of switching to GitHub for code hosting? Contributors won't > be disrupted at all since most people are more familiar with GitHub vs. > Bitbucket (how many

Re: [Python-Dev] https://docs.python.org/3/using/index.html not linking correctly

On 10/20/2014 10:01 PM, Terry Reedy wrote: > If I go to https://docs.python.org/3/using/index.html and click on any > of the TOC entries, I get 'connecting' indefinitely. This problem seems > unique to this file. I tried several other index files and clicking am > entry brings up the correspond

[Python-Dev] [RELEASED] Python 3.2.6, Python 3.3.6

These are production versions, please report any bugs to http://bugs.python.org/ Enjoy! - -- Georg Brandl, Release Manager georg at python.org (on behalf of the entire python-dev team and contributors) -BEGIN PGP SIGNATURE- Version: GnuPG v2 iEYEARECAAYF

Re: [Python-Dev] bytes-like objects

On 10/06/2014 06:34 AM, Nick Coghlan wrote: > 3. "buffer" is a completely new term for most users, and one that > refers to an implementation detail of memoryview, moreso than > something developers actually need to care about. Using it directly in > error messages and documentation is to make the

Re: [Python-Dev] bytes-like objects

On 10/05/2014 06:11 PM, R. David Murray wrote: > Over the past while we've been cleaning up the docs in the area of "how > do we refer to bytes, bytearray, memoryview, etc, etc?" in the APIs that > deal with bytes. As you may or may not remember, we settled on the term > 'bytes-like object', and h

Re: [Python-Dev] Microsoft Visual C++ Compiler for Python 2.7

I just tried out the compiler and built wininst and wheel dists. Thanks! distutils was *almost* fine using it, but for two snags: * I had to set VS90COMNTOOLS * distutils expects vcvarsall.bat in VC, while you have it in the parent dir The first could be set by the installer of your package. B

[Python-Dev] [RELEASED] Python 3.2.6rc1, Python 3.3.6rc1

https://www.python.org/downloads/release/python-336rc1/ These are pre-releases, please report any bugs to http://bugs.python.org/ The final releases are scheduled one week from now. Enjoy! - -- Georg Brandl, Release Manager georg at python.org (on behalf of the entire python-dev team and contrib

Re: [Python-Dev] Multiline with statement line continuation

On 08/15/2014 11:08 PM, Ethan Furman wrote: > On 08/13/2014 10:32 AM, Steven D'Aprano wrote: >> >> (2) Also note that *this is already the case*, since tuples are made by >> the commas, not the parentheses. E.g. this succeeds: >> >> # Not a tuple, actually two context managers. >> with open("/tmp/f

Re: [Python-Dev] Multiline with statement line continuation

On 08/12/2014 06:57 PM, Armin Rigo wrote: > Hi, > > On 12 August 2014 01:08, Allen Li wrote: >> with (open('foo') as foo, >> open('bar') as bar, >> open('baz') as baz, >> open('spam') as spam, >> open('eggs') as eggs): >> pass > > +1. It's exa

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

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 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 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] 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] 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] 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] 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

[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: 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

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] 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] 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] 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 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] 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] 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] 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

[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] 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 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] 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

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 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] 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 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] 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 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 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] 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.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] 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] 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] 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] 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

[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] 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

Re: [Python-Dev] __doc__ regression

Am 04.02.2014 14:19, schrieb Victor Stinner: > 2014-02-04 Larry Hastings : >> Why couldn't these tools use inspect.Signature? > > inspect.Signature was added in Python 3.3. Python 2 is still widely > used, and some Linux distro only provide Python 3.2. Well, Python 2 won't be able to introspect C

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

Am 04.02.2014 13:14, schrieb Antoine Pitrou: > On Tue, 04 Feb 2014 02:21:51 -0800 > Larry Hastings wrote: >> On 02/04/2014 01:41 AM, Georg Brandl wrote: >> > Clever, but due to the "hidden" space it also increases the frustration >> > factor >>

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

Am 04.02.2014 10:12, schrieb Larry Hastings: > If you won't let me have a flag, can I at least have a more-clever marker? > How > about this: > > (...)\n \n > > Yes, the last four characters are right-parenthesis, newline, space, and > newline. Benefits: > > * The odds of finding *that

Re: [Python-Dev] [RELEASED] Python 3.3.4 release candidate 1

Am 29.01.2014 20:12, schrieb Serhiy Storchaka: > 29.01.14 18:55, Andrew Svetlov написав(ла): >> Would you to accept fixes for http://bugs.python.org/issue20434 and >> http://bugs.python.org/issue20437 before 3.3.4 final? > > And http://bugs.python.org/issue20440. No, sorry; these bugs are not reg

Re: [Python-Dev] Negative times behaviour in itertools.repeat for Python maintenance releases (2.7, 3.3 and maybe 3.4)

Am 27.01.2014 13:12, schrieb Antoine Pitrou: > On Mon, 27 Jan 2014 04:01:02 -0800 > Larry Hastings wrote: >> >> On 01/27/2014 01:39 AM, Antoine Pitrou wrote: >> > On Sun, 26 Jan 2014 21:01:08 -0800 >> > Larry Hastings wrote: >> >> On 01/26/2014 08:40 PM, Alexander Belopolsky wrote: >> >>> On Sun

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

http://www.python.org/download/releases/3.3.4/ This is a preview release, please report any bugs to http://bugs.python.org/ The final version is scheduled to be released in two weeks' time, on or about the 10th of February. Enjoy! - -- Georg Brandl, Release Manager georg at pyth

Re: [Python-Dev] version numbers mismatched in google search results.

Am 25.01.2014 17:12, schrieb Benjamin Peterson: > On Sat, Jan 25, 2014, at 05:47 AM, Vincent Davis wrote: >> When I do a google search the version numbers are mismatched with the >> linked page (or redirected). >> For example search for "python counter" I get the following results. (see >> attachme

Re: [Python-Dev] [Python-checkins] Cron /home/docs/build-devguide

Am 25.01.2014 05:49, schrieb Benjamin Peterson: > On Fri, Jan 24, 2014, at 08:45 PM, Cron Daemon wrote: >> Could not find platform independent libraries >> Could not find platform dependent libraries >> Consider setting $PYTHONHOME to [:] >> 'import site' failed; use -v for traceback >> Traceback

Re: [Python-Dev] .clinic.c vs .c.clinic

Am 20.01.2014 09:15, schrieb Georg Brandl: >> Contestant 5: "Put in __clinic__ directory, add .h" >> >> foo.c -> __clinic__/foo.c.h >> foo.h -> __clinic__/foo.h.h > > -1. (Too complicated; this isn't Python p

Re: [Python-Dev] .clinic.c vs .c.clinic

Am 20.01.2014 22:47, schrieb Ethan Furman: >>> Won't AC put those macros in the source file for you? >> >> No, currently it wouldn't know where to look. And that's a good thing >> because AC never should modify anything not inbetween "clinic start >> generated code" and "clinic end generated code

Re: [Python-Dev] .clinic.c vs .c.clinic

Am 20.01.2014 21:05, schrieb Ethan Furman: > On 01/20/2014 11:46 AM, Brett Cannon wrote: >> On Mon, Jan 20, 2014 at 2:09 PM, Barry Warsaw wrote: >>> On Jan 20, 2014, at 12:05 AM, Larry Hastings wrote: >>> Contestant 5: "Put in __clinic__ directory, add .h" foo.c -> __clinic__/foo.

Re: [Python-Dev] .clinic.c vs .c.clinic

Am 20.01.2014 14:31, schrieb Serhiy Storchaka: > 20.01.14 15:03, Nick Coghlan написав(ла): >> On 20 January 2014 21:14, Serhiy Storchaka wrote: >>> 20.01.14 10:05, Larry Hastings написав(ла): Contestant 4: "Put in clinic directory, add .h" foo.c -> clinic/foo.c.h foo.

  1   2   3   4   5   6   7   8   9   10   >