Re: [Python-Dev] [Python-checkins] cpython: Issue #22003: When initialized from a bytes object, io.BytesIO() now
I'd like to point out a couple of compiler warnings on Windows:
On Tue, Jul 29, 2014 at 6:45 PM, antoine.pitrou
wrote:
> diff --git a/Modules/_io/bytesio.c b/Modules/_io/bytesio.c
> --- a/Modules/_io/bytesio.c
> +++ b/Modules/_io/bytesio.c
> @@ -33,6 +37,45 @@
> return NULL; \
> }
>
> +/* Ensure we have a buffer suitable for writing, in the case that an
> initvalue
> + * object was provided, and we're currently borrowing its buffer. `size'
> + * indicates the new buffer size allocated as part of unsharing, to avoid a
> + * redundant reallocation caused by any subsequent mutation. `truncate'
> + * indicates whether truncation should occur if `size` < self->string_size.
> + *
> + * Do nothing if the buffer wasn't shared. Returns 0 on success, or sets an
> + * exception and returns -1 on failure. Existing state is preserved on
> failure.
> + */
> +static int
> +unshare(bytesio *self, size_t preferred_size, int truncate)
> +{
> +if (self->initvalue) {
> +Py_ssize_t copy_size;
> +char *new_buf;
> +
> +if((! truncate) && preferred_size < self->string_size) {
..\Modules\_io\bytesio.c(56): warning C4018: '<' : signed/unsigned mismatch
> +preferred_size = self->string_size;
> +}
> +
> +new_buf = (char *)PyMem_Malloc(preferred_size);
> +if (new_buf == NULL) {
> +PyErr_NoMemory();
> +return -1;
> +}
> +
> +copy_size = self->string_size;
> +if (copy_size > preferred_size) {
..\Modules\_io\bytesio.c(67): warning C4018: '>' : signed/unsigned mismatch
> +copy_size = preferred_size;
> +}
> +
> +memcpy(new_buf, self->buf, copy_size);
> +Py_CLEAR(self->initvalue);
> +self->buf = new_buf;
> +self->buf_size = preferred_size;
> +self->string_size = (Py_ssize_t) copy_size;
> +}
> +return 0;
> +}
>
> /* Internal routine to get a line from the buffer of a BytesIO
> object. Returns the length between the current position to the
--
Zach
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] Daily reference leaks (09f56fdcacf1): sum=21004
On Thu, Aug 7, 2014 at 9:04 AM, Brett Cannon wrote: > test_codecs is not happy. Looking at the subject lines of commit emails from > the past day I don't see any obvious cause. Looks like this was caused by the change I made to regrtest in [1] to fix refleak testing in test_asyncio [2]. I'm looking into it, but haven't found any kind of reason for it yet. -- Zach [1] http://hg.python.org/cpython/rev/7bc53cf8b2df [2] http://bugs.python.org/issue22104 ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] Daily reference leaks (09f56fdcacf1): sum=21004
On Thu, Aug 7, 2014 at 12:16 PM, Zachary Ware wrote: > On Thu, Aug 7, 2014 at 9:04 AM, Brett Cannon wrote: >> test_codecs is not happy. Looking at the subject lines of commit emails from >> the past day I don't see any obvious cause. > > Looks like this was caused by the change I made to regrtest in [1] to > fix refleak testing in test_asyncio [2]. I'm looking into it, but > haven't found any kind of reason for it yet. I've created http://bugs.python.org/issue22166 to keep track of this and report my findings thus far. -- Zach ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fixing 2.7.x
On Mon, Oct 6, 2014 at 12:24 PM, Ned Deily wrote: > 3. security: "fixing issues exploitable by attackers such as crashes, > privilege escalation and, optionally, other issues such as denial of > service attacks. Any other changes are not considered a security risk > and thus not backported to a security branch." >= 3.2.x and 3.3.x 3.1 is still in this category, is it not? According to PEP 375, it's a few months past due for its last release. http://legacy.python.org/dev/peps/pep-0375/#maintenance-releases -- Zach ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fixing 2.7.x
On Mon, Oct 6, 2014 at 2:18 PM, Christian Tismer wrote: > My impression is that no 3.X user ever would want to stick > with any older version. > > Is that true, or am I totally wrong? My impression is that you're mostly right, but only because those who would still be on 3.1 are actually still on 2.5 ;). However as one who uses 3.x exclusively, I do still use 3.2 on a regular basis simply because it's the last release to support Windows 2000 and it does everything I need to do on that platform. Either way, that seems a bit tangential to my original point, which was that 3.1 is still technically an open security branch which is due to be closed (with or without it's last security release, which was due in June). -- Zach ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status of C compilers for Python on Windows
On Sat, Oct 25, 2014 at 7:05 PM, Ray Donnelly wrote: > On Sun, Oct 26, 2014 at 12:30 AM, Antoine Pitrou wrote: >> On Sat, 25 Oct 2014 19:24:38 -0400 >> "R. David Murray" wrote: >>> >>> I know I for one do not generally test patches on Windows because I >>> haven't taken the time to learn how to build CPython on it. Sure, I >>> could test pure python changes by applying patches to an installed >>> Python, but that's an ongoing pain and I'd rather learn to build CPython >>> on Windows and get to use the normal hg tools. >>> >>> If I could use a more linux-like toolchain to build CPython on windows, >> >> Well, I don't know how "linux-like" you want your toolchain, but FTR >> you should be able to build from the command line by running >> "Tools\buildbot\build.bat". >> >> I doubt the MinGW case can be much simpler :-) >> > > I beg to differ: > > "Tools\buildbot\build.bat" contains: > @rem Used by the buildbot "compile" step. > cmd /c Tools\buildbot\external.bat > call "%VS100COMNTOOLS%vsvars32.bat" > cmd /c Tools\buildbot\clean.bat > msbuild PCbuild\pcbuild.sln /p:Configuration=Debug /p:Platform=Win32 > > ^ this involves purchasing and installing MS Visual Studio (I'm not > sure if the Express Edition can be used). The Express Edition is fine for 32-bit builds. PCbuild\readme.txt has full details on which editions are needed for what, and in 3.5 also has a "quick start guide" (absent from older versions due to a rewriting of the batch scripts that I did a while back): 1. Install Microsoft Visual C++ 2010 SP1, any edition. 2. Install Subversion, and make sure 'svn.exe' is on your PATH. 3. Install NASM, and make sure 'nasm.exe' is on your PATH. 4. Run "build.bat -e" to build Python in 32-bit Release configuration. 5. (Optional, but recommended) Run the test suite with "rt.bat -q". And really, you can skip step 5 if you don't want to run the tests; you can skip step 3 if you don't want/need ssl; and you can skip step 2 if you don't want/need bz2, lzma, sqlite3, ssl, or tkinter. Skipping steps 2 or 3 will cause a lot of angry red text in your build output, but I hope to solve that problem eventually. > Without explanations for what each step is doing (I posted those last > week), on MSYS2: > Download and run: > http://sourceforge.net/projects/msys2/files/Base/x86_64/msys2-x86_64-20141003.exe/download > From the MSYS2 shell: > pacman -S git base-devel mingw-w64-x86_64-toolchain > mingw-w64-i686-toolchain > git clone https://github.com/Alexpux/MINGW-packages > cd MINGW-packages/mingw-w64-python3 > makepkg-mingw -sL --nocheck > (remove --nocheck to run the testsuite. Also you could put this into a > batch file if you were so inclined.) > > To install the newly built packages, from the MSYS2 shell again: > pacman -U mingw-w64-*.xz > > To run them, you should add /mingw64/bin or /mingw32/bin to your PATH > (or launch a new shell via mingw32_shell.bat or mingw64_shell.bat) > Of course, if you don't want to build it from source you can simply issue: > pacman -S mingw-w64-python3 > > .. all of the above applies equally to mingw-w64-python2. I'm failing to see where that's simpler :) For the record, on the issue at hand, I agree that any effort should go toward making it possible to build extensions without MSVC. Once that problem has been completely solved, then we can consider (long and hard) building Python itself with something else. I personally have not been convinced that there's any good reason to do so, but I'm not unconvincible :) -- Zach ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status of C compilers for Python on Windows
On Sat, Oct 25, 2014 at 6:24 PM, R. David Murray wrote: > Note: it can be made even less compelling by making it a lot easier to > build CPython on Windows without having an MSVC license (which I think > means not using the GUI, for which I say *yay* :). I think Zach Ware > has been working on improving the Windows build process, and I keep > meaning to give it a try... So far my improvements have been limited to what it takes to build after installing prerequisites (and documenting what exactly those prerequisites are), but on that front things are significantly better in 3.5, I think. I will note that it's been possible to build Python entirely without using the VS GUI (though it still has to be installed, I think) for quite some time, but hasn't been especially easy to remember the incantations to do so. 3.5 now has a fairly nice set of batch scripts (I think; but I (re)wrote them :) that work well together and are even documented in the PCbuild readme. I've had dreams of a set of configure.bat/make.bat scripts (issue16895) to make things even simpler, but I've put that on hold until after Steve Dower's major overhaul for VC14 has happened. One thing I'd like to look into more eventually is seeing what it would take to build with only the Windows SDK installed (which is free and has no GUI at all), but I think Steve has mentioned something about that in connection with the work he's doing -- either way, things will be different when we switch to VC14 so I'm also putting that off. -- Zach ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Compile Python on Windows (OpenSSL)
On Tue, Jan 13, 2015 at 4:04 PM, Victor Stinner wrote: > Hi, > > To compile Python on Windows, there are a few information in the > Developer Guide: > https://docs.python.org/devguide/setup.html#windows-compiling > > Python 3.5 now requires Visual Studio 2010 *SP1*, or newer Visual Studio: > http://bugs.python.org/issue22919#msg233637 > > I found PCbuild\readme.txt which is not mentionned in the devguide :-/ > https://hg.python.org/cpython/file/56f717235c45/PCbuild/readme.txt > (at least not on the Windows section of the setup page) The first line of the section you linked to is "The readme included in the solution has more details, especially on what additional software is required to build which parts of Python.", and 'readme' is a link to the readme on h.p.o. :) > I found some clues to build OpenSSL to be able to build the Python ssl > module, but I still have issues. > > Is there a more complete documentation? The readme *should* be fairly comprehensive as I rewrote it last year, but it may still be lacking since I wrote it after doing regular builds for a year or two. In particular, the Quick Start guide at the very beginning of the readme should be enough to get you going. """ Quick Start Guide - 1. Install Microsoft Visual Studio 2015, any edition. 2. Install Subversion, and make sure 'svn.exe' is on your PATH. 3. Run "build.bat -e" to build Python in 32-bit Release configuration. 4. (Optional, but recommended) Run the test suite with "rt.bat -q". """ That should be enough to build Python, OpenSSL, Tcl/Tk/Tix, and all other external projects. One thing that might be a gotcha there, if you're using a Command Prompt window that you opened before installing SVN, you'll need to either adjust PATH manually or open a new Command Prompt to get the PATH changes. > I found how to install svn.exe, perl.exe and nasm.exe, but not how to > install nmake.exe. I don't know the command to build OpenSSL. Perl is not necessary if you're using sources from svn.python.org (which "build.bat -e" will do). You also no longer need to install NASM. nmake.exe is part of Visual Studio (or the Windows SDK, whichever). > I don't care of building OpenSSL, my goal is only to build the Python > ssl module. Is there a way to install a development version of OpenSSL > (.lib files if I remember correctly) from an installer/binary? > > My draft notes: > > +Compile CPython on Windows > +== > + > +To build the Python ssl extension: > + > +Need: > + > +* Visual Studio 2010 SP1 or newer > +* CPython source code (default branch: 3.5) > +* perl binary: ActivePerl > +* svn binary, ex: SilkSVN > +* nasm and nmake binaries: compile NASM (install the binary doesn't > install nmake) > + > +Read PCbuild/readme.txt. > + > +* Build Python (in debug mode) > +* Type: PCbuild\get_externals.bat > +* Type: PCbuild\win32\python_d.exe PCbuild\prepare_ssl.py > externals\openssl-1.0.1j You don't need to use prepare_ssl.py if you use get_externals.bat. The 'ssl' section of the readme should cover that (if it can be clarified, please point out the problems to me!). -- Zach ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Compile Python on Windows (OpenSSL)
On Tue, Jan 13, 2015 at 4:15 PM, Zachary Ware wrote: > """ > Quick Start Guide > - > > 1. Install Microsoft Visual Studio 2015, any edition. Note that this isn't precisely true; any VS 2010 SP1 or newer *should* work, as you already know :). This just says 2015 because that's the 'official' version to use. -- Zach ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Compile Python on Windows (OpenSSL)
On Thu, Jan 15, 2015 at 3:30 PM, Victor Stinner wrote: > Hi, > > I installed the SP1 for Visual Studio 2010, and it looks like that it > broke my Windows SDK 7.1 (setenv was missing, cl.exe was also > missing). I uninstalled the SDK 7.1, and then I saw that a patch is > required to use Windows SDK 7.1 with Visual Studio 2010 SP1. Ah. Too > late. Doing a 'repair' on VS2010 might get the SDK back for you; I'm not sure. I believe this link should be what's needed to fix the SDK after installing VS2010SP1: http://www.microsoft.com/en-us/download/details.aspx?id=4422 > I don't understand the link between the SDK and Visual Studio. There > are not separated directories? If I'm not mistaken, Visual Studio uses the SDK for all of its building and will install its preferred SDK as a dependency. It can use other SDKs as well, though. > And now I cannot find Windows SDK 7.1 anymore. It looks like it > disappeared from microsoft.com. The SDK 7.1 was released in 2010, so > it's now quite old, but it worked well! Web installer: http://www.microsoft.com/en-us/download/details.aspx?id=8279 ISOs: http://www.microsoft.com/en-us/download/details.aspx?id=8442 Extension building in general is still a mess on Windows, I hope the links above are enough to get you going again! -- Zach ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Can Python Be Built Without Distutils
On Saturday, January 24, 2015, Brett Cannon wrote: > On Fri Jan 23 2015 at 5:45:28 PM Gregory P. Smith > wrote: > >> On Fri Jan 23 2015 at 11:20:02 AM M.-A. Lemburg > > wrote: >> >>> On 23.01.2015 19:48, Matthias Klose wrote: >>> > On 01/23/2015 06:30 PM, Cyd Haselton wrote: >>> >> Related to my earlier question regarding building Python on Android >>> >> and an undefined reference to dlopen error...I have the following >>> >> question: Is it possible to build and install Python without having >>> >> to build and install...or use...distutils? >>> >> >>> >> Some background: >>> >> I can build the python interpreter on my device, and I can build a >>> >> bunch of modules. The problem appears when make reaches the part >>> >> where setup.py is used to build and import modules...specifically when >>> >> setup.py attempts to import distutils.core. >>> > >>> > you can do this using Setup.local. This works for me building >>> additional >>> > extensions as builtins. It might require some tweaking to build >>> everything. >>> >>> You may want to have a look at the Setup files we're using >>> in eGenix PyRun, which uses them to force static builds of the >>> various built-in extensions. >>> >>> Look for these files: >>> >>> PyRun/Runtime/Setup.PyRun-2.7 >>> PyRun/Runtime/Setup.PyRun-3.4 >>> >>> in the source archives: >>> >>> http://www.egenix.com/products/python/PyRun/ >>> >>> > Otoh, I would like to get rid off the setup.py altogether (/me ducks >>> ...). >>> >>> Why ? It's great for finding stuff on your system and configuring >>> everything without user intervention (well, most of the time :-)). >>> >> >> Because our setup.py is a nightmare of arbitrary code run in a linear >> fashion with ad-hoc checks for things that are unlike how any other project >> on the planet determines what is available on your system. It may have >> seemed "great" when it was created in 2001. It really shows its age now. >> >> It defeats build parallelism and dependency declaration. >> It also prevents cross compilation. >> >> Building an interpreter with a limited standard library on your build >> host so that you can run said interpreter to have it drive the remainder of >> your build is way more self hosting that we rightfully need to be for >> CPython. >> > > So are you suggesting to add the build rules to configure and the Makefile > -- and Windows build file -- in order to drop setup.py? > Windows already doesn't use setup.py. There are a lot more modules built-in on Windows, and others have their own project files; distutils isn't used at all. -- Sent from Gmail Mobile ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pydoc Replacement for Python's help()?
On Mon, Jan 26, 2015 at 12:49 PM, Cyd Haselton wrote: > Hello, > I've finally managed to build a (somewhat) working Python port for the > Android tablet I'm using. Unfortunately, as I quickly found out, > Python's built-in help function requires tkinter, which requires > tcl/tk. What version of Python are you building, and how did you call help that it seems to want to use tkinter? The pydoc GUI was removed from the 3.x series long ago, and should only be activated in 2.7 if you call it as 'pydoc -g ...' from the command line (or use pydoc.gui() directly). -- Zach ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Building on Windows - importlib.h changed
On Fri, Feb 13, 2015 at 4:09 PM, Paul Moore wrote: > I'm working on a patch for the Python launcher. I built Python > (current tip, on MS Windows, with VS 2015), and I've just noticed that > hg status shows: > >>>hg status -mard > M Doc\using\windows.rst > M PC\launcher.c > M Python\importlib.h > > I didn't change importlib.h, and I don't see that the changes I did > make would affect importlib. I presume I'm OK *not* including the > importlib.h change in my patch? Yes, importlib.h changes should never be included in a patch (it would make the patch extremely huge for no benefit). It's strange that you're getting modifications, though; I can't reproduce on Linux (and don't have quick access to Windows right now). Make sure you're definitely at tip, and if it's still changing please open an issue. -- Zach ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Building on Windows - importlib.h changed
On Fri, Feb 13, 2015 at 4:56 PM, Eric Snow wrote: > On Fri, Feb 13, 2015 at 3:49 PM, Zachary Ware > wrote: >> Yes, importlib.h changes should never be included in a patch (it would > > Unless they should. :) E.g. you modified importlib/_bootstrap.py, the > marshal format, bytecodes, etc. If I'm not mistaken, the devguide suggests leaving generated files out of patches, though I can't find where to link to it. If not, it probably should :). Generated files ought to be generated by the build process the same way on any system, so leaving them in the patch amounts to unnecessary noise, especially in the case of importlib.h which is not human-readable (and huge). In the case of a generated file being affected by a patch, a friendly reminder that files will need to be regenerated should be included when posting the patch, though. -- Zach ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3.4 RPM on AIX
On Mon, Feb 16, 2015 at 10:50 PM, Blaxton wrote: > I am using the spec file that comes with Python source code which downloaded > from python.org website > source file is set on spec file to file with bz2 format while there is only > .xz and zipped are available to download. > > > I thought somehow some one from development team has wrote that .spec file > and maybe supporting it. > > This is like no support. The spec file in Misc/RPM has not been maintained in quite some time; the last change to that file that wasn't just a version bump was one [1] whose commit message was "#5776: fix mistakes in python specfile. (Nobody probably uses it anyway.)" and was committed four and a half years ago. It's not unlikely that you're the first person to use the file since then :). We should probably just remove the file, but if you manage to get it working and would like to provide a patch on bugs.python.org, it would probably be accepted. [1] https://hg.python.org/cpython/rev/ef75ecd0e1a7 -- Zach ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] libffi embedded in CPython
I started this message about 3 months ago; at this point I'm just getting it posted so it stops rotting in my Drafts folder. On Mon, Dec 22, 2014 at 3:49 PM, Jim J. Jewett wrote: > On Thu, Dec 18, 2014, at 14:13, Maciej Fijalkowski wrote: >> ... http://bugs.python.org/issue23085 ... >> is there any reason any more for libffi being included in CPython? > > > Paul Moore wrote: >> Probably the easiest way of moving this forward would be for someone >> to identify the CPython-specific patches in the current version ... > > Christian Heimes wrote: >> That's easy. All patches are tracked in the diff file >> https://hg.python.org/cpython/file/3de678cd184d/Modules/_ctypes/libffi.diff > > That (200+ lines) doesn't seem to have all the C changes, such as the > win64 sizeof changes from issue 11835. I took a little bit of time to look at this a while ago. Something that quickly became clear that I'm not sure everybody is on the same page about (I, for one, had no idea previously) is that libffi for Windows and libffi for everything else are entirely separate beasts: the Windows build pulls all of its libffi source from Modules/_ctypes/libffi_msvc and doesn't even touch Modules/_ctypes/libffi (which is libffi for nearly everything else). Most of the files in libffi_msvc haven't been touched in about 4 years, except for a couple fixes by Steve Dower recently. README.ctypes in that folder states that the files were taken from the libffi CVS tree in 2004 and there have been some custom modifications since then, so there is really very little resemblance between libffi_msvc and current libffi. There's also 'libffi_arm_wince' and 'libffi_osx'. I would be fairly amazed if Python itself built on any version of Windows CE; personally I would be for ripping out any supposed support that we have for it (though if somebody is actually using it and it works, it's not hurting anything and should stay). That's a completely different issue, though. I'm all for ditching our 'libffi_msvc' in favor of adding libffi as another 'external' for the Windows build. I have managed to get _ctypes to build on Windows using vanilla libffi sources, prepared using their configure script from within Git Bash and built with our usual Windows build system (properly patched). Unfortunately, making things usable will take some work on ctypes itself, which I'm not qualified to do. I'm happy to pass on my procedure and patches for getting to the point of successful compilation to anyone who feels up to fixing the things that are broken. As for the lightly-patched version of libffi that we keep around for Linux et. al., looking at the diff file I don't see that there's a whole lot of reason to keep it around. -- Zach ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] libffi embedded in CPython
On Thu, Mar 12, 2015 at 12:44 PM, Paul Moore wrote: > I'd be willing to contemplate helping out on the Windows side of > things, if nobody else steps up (with the proviso that I have little > free time, and I'm saying this without much idea of what's involved > :-)) If Zachary can give a bit more detail on what the work on ctypes > is, and/or put what he has somewhere that I could have a look at, that > might help. I'll send you everything I've got next chance I have, but I don't know when that will be. -- Zach ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] libffi embedded in CPython
On Mar 25, 2015 4:22 AM, "Paul Moore" wrote: > > On 25 March 2015 at 09:09, Antoine Pitrou wrote: > > I'm not sure we guarantee anything. In any case, it's only a small > > proportion of the kind of crashes you can get by messing the signature. > > Fair point. I guess what I'm asking is, would it be OK to remove the > code that checks for a stack size discrepancy and raises ValueError, > and the tests that verify this behaviour, as part of switching to > using upstream libffi directly? > > On a related note, is there any information available on how the > "externals" repo is maintained? In particular, should things in there > be exact copies of upstream, or is it OK to include extra data (in > this case, the results of running "configure" for the Windows build)? > It works for me either way, it's just a matter of how the build > process would be structured and maintained. Its not extremely clear how it's "supposed to be" done; look at the differences between how we handle OpenSSL and Tcl/Tk, for example. One way or the other, though, we will store the configure output so that our build doesn't depend on any more than it absolutely has to. -- Zach On a phone ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] libffi embedded in CPython
On Mar 25, 2015 9:28 PM, "Nick Coghlan" wrote: > > On 26 March 2015 at 01:57, Steve Dower wrote: > > Zachary Ware wrote: > >> On Mar 25, 2015 4:22 AM, "Paul Moore" wrote: > >>> On a related note, is there any information available on how the > >>> "externals" repo is maintained? In particular, should things in there > >>> be exact copies of upstream, or is it OK to include extra data (in > >>> this case, the results of running "configure" for the Windows build)? > >>> It works for me either way, it's just a matter of how the build > >>> process would be structured and maintained. > >> > >> Its not extremely clear how it's "supposed to be" done; look at the differences > >> between how we handle OpenSSL and Tcl/Tk, for example. One way or the other, > >> though, we will store the configure output so that our build doesn't depend on > >> any more than it absolutely has to. > > > > It would be nice for at least one other person to know how to do it. I can't see the SVN logs, but I feel like you're the only person who's touched it in a while :) > > > > As well as the configure output, we sometimes include very light patching (for example, Tcl/Tk currently has a patch to their makefile to work around a VC14 bug). I'm not sure whether that's considered good practice or not, but I prefer only needing to do it once vs. building it into the build system. > > It likely makes sense to try to at least write down the status quo > regarding the externals repo as a new top level section in the > Developer's Guide. That way you'll at least have a shared > understanding of the starting point for any further improvements. I'll try to get something thrown together at least by the time I leave PyCon. Unfortunately I can't guarantee anything sooner than that. -- Zach On a phone ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: Check deques against common sequence tests (except for slicing).
On Wed, Apr 1, 2015 at 10:11 AM, raymond.hettinger wrote: > https://hg.python.org/cpython/rev/393189326adb > changeset: 95350:393189326adb > user:Raymond Hettinger > date:Wed Apr 01 08:11:09 2015 -0700 > summary: > Check deques against common sequence tests (except for slicing). > > files: > Lib/test/test_deque.py | 16 > 1 files changed, 16 insertions(+), 0 deletions(-) > > > diff --git a/Lib/test/test_deque.py b/Lib/test/test_deque.py > --- a/Lib/test/test_deque.py > +++ b/Lib/test/test_deque.py > @@ -843,6 +843,21 @@ > # SF bug #1486663 -- this used to erroneously raise a TypeError > SubclassWithKwargs(newarg=1) > > +class TestSequence(seq_tests.CommonTest): > +type2test = deque > + > +def test_getitem(self): > +# For now, bypass tests that require slicing > +pass > + > +def test_getslice(self): > +# For now, bypass tests that require slicing > +pass > + > +def test_subscript(self): > +# For now, bypass tests that require slicing > +pass Instead of making these empty passing tests, it's better to set them to 'None' so that unittest doesn't run them (and thus doesn't report success when it hasn't actually tested something). -- Zach ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] version of freshly built 2.7 python
On Thursday, April 2, 2015, Ethan Furman wrote: > I just built the latest version of Python 2.7 on my development machine -- > or so I thought. When I invoke it, I get: > > Python 2.7.6+ (2.7:1beb3e0507fa, Apr 2 2015, 17:57:53) > > Why am I not seeing 2.7.9? > https://hg.python.org/cpython/rev/1beb3e0507fa/ I'd say update and try again. Taking a wild guess as to why you're on the wrong revision, if you use the hg 'share' extension to keep separate working copies of each branch, remember that 'hg pull --update' doesn't update if you already have all changesets from the server due to a pull in another 'shared' copy. Hope this helps, -- Zach -- Sent from Gmail Mobile ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Python3 Stable ABI
In issue23903, I've created a script that will produce PC/python3.def by scraping the header files in Include. There are are many many discrepencies between what my script generates and what is currently in the repository (diff below), but in every case I've checked the script has been right: what the script finds is actually exported as part of the limited API, but due to not being in the .def file it's not actually exported from python3.dll. Almost all of the differences are things that the script found that weren't present, but there are a couple things going the other way. The point of this message is to ask everybody who maintains anything in C to take a look through and make sure everything in their area is properly guarded (or not) by Py_LIMITED_API. Alternately, if somebody can find a bug in my script and brain that's finding too much stuff, that would be great too. Ideally, after this is all settled I'd like to add the script to both the Makefile and the Windows build system, such that PC/python3.def is always kept up to date and flags changes that weren't meant to be made. Regards, -- Zach (I'm afraid Gmail might mangle this beyond recognition, you can find the diff at http://bugs.python.org/review/23903/diff/14549/PC/python3.def if it does.) diff -r 24f2c0279120 PC/python3.def --- a/PC/python3.defMon Apr 13 15:51:59 2015 -0500 +++ b/PC/python3.defMon Apr 13 16:10:34 2015 -0500 @@ -1,13 +1,15 @@ ; This file specifies the import forwarding for python3.dll ; It is used when building python3dll.vcxproj +; Generated by python3defgen.py, DO NOT modify directly! LIBRARY"python3" EXPORTS + PyAST_FromNode=python35.PyAST_FromNode + PyAST_FromNodeObject=python35.PyAST_FromNodeObject + PyAST_Validate=python35.PyAST_Validate PyArg_Parse=python35.PyArg_Parse PyArg_ParseTuple=python35.PyArg_ParseTuple PyArg_ParseTupleAndKeywords=python35.PyArg_ParseTupleAndKeywords PyArg_UnpackTuple=python35.PyArg_UnpackTuple - PyArg_VaParse=python35.PyArg_VaParse - PyArg_VaParseTupleAndKeywords=python35.PyArg_VaParseTupleAndKeywords PyArg_ValidateKeywordArguments=python35.PyArg_ValidateKeywordArguments PyBaseObject_Type=python35.PyBaseObject_Type DATA PyBool_FromLong=python35.PyBool_FromLong @@ -39,7 +41,6 @@ PyCFunction_GetFlags=python35.PyCFunction_GetFlags PyCFunction_GetFunction=python35.PyCFunction_GetFunction PyCFunction_GetSelf=python35.PyCFunction_GetSelf - PyCFunction_New=python35.PyCFunction_New PyCFunction_NewEx=python35.PyCFunction_NewEx PyCFunction_Type=python35.PyCFunction_Type DATA PyCallIter_New=python35.PyCallIter_New @@ -58,6 +59,7 @@ PyCapsule_SetPointer=python35.PyCapsule_SetPointer PyCapsule_Type=python35.PyCapsule_Type DATA PyClassMethodDescr_Type=python35.PyClassMethodDescr_Type DATA + PyCmpWrapper_Type=python35.PyCmpWrapper_Type DATA PyCodec_BackslashReplaceErrors=python35.PyCodec_BackslashReplaceErrors PyCodec_Decode=python35.PyCodec_Decode PyCodec_Decoder=python35.PyCodec_Decoder @@ -68,6 +70,7 @@ PyCodec_IncrementalEncoder=python35.PyCodec_IncrementalEncoder PyCodec_KnownEncoding=python35.PyCodec_KnownEncoding PyCodec_LookupError=python35.PyCodec_LookupError + PyCodec_NameReplaceErrors=python35.PyCodec_NameReplaceErrors PyCodec_Register=python35.PyCodec_Register PyCodec_RegisterError=python35.PyCodec_RegisterError PyCodec_ReplaceErrors=python35.PyCodec_ReplaceErrors @@ -122,6 +125,7 @@ PyErr_Fetch=python35.PyErr_Fetch PyErr_Format=python35.PyErr_Format PyErr_FormatV=python35.PyErr_FormatV + PyErr_GetExcInfo=python35.PyErr_GetExcInfo PyErr_GivenExceptionMatches=python35.PyErr_GivenExceptionMatches PyErr_NewException=python35.PyErr_NewException PyErr_NewExceptionWithDoc=python35.PyErr_NewExceptionWithDoc @@ -132,14 +136,25 @@ PyErr_PrintEx=python35.PyErr_PrintEx PyErr_ProgramText=python35.PyErr_ProgramText PyErr_Restore=python35.PyErr_Restore + PyErr_SetExcFromWindowsErr=python35.PyErr_SetExcFromWindowsErr + PyErr_SetExcFromWindowsErrWithFilename=python35.PyErr_SetExcFromWindowsErrWithFilename + PyErr_SetExcFromWindowsErrWithFilenameObject=python35.PyErr_SetExcFromWindowsErrWithFilenameObject + PyErr_SetExcFromWindowsErrWithFilenameObjects=python35.PyErr_SetExcFromWindowsErrWithFilenameObjects + PyErr_SetExcInfo=python35.PyErr_SetExcInfo + PyErr_SetExcWithArgsKwargs=python35.PyErr_SetExcWithArgsKwargs PyErr_SetFromErrno=python35.PyErr_SetFromErrno PyErr_SetFromErrnoWithFilename=python35.PyErr_SetFromErrnoWithFilename PyErr_SetFromErrnoWithFilenameObject=python35.PyErr_SetFromErrnoWithFilenameObject + PyErr_SetFromErrnoWithFilenameObjects=python35.PyErr_SetFromErrnoWithFilenameObjects + PyErr_SetFromWindowsErr=python35.PyErr_SetFromWindowsErr + PyErr_SetFromWindowsErrWithFilename=python35.PyErr_SetFromWindowsErrWithFilename + PyErr_SetImportError=python35.PyErr_SetImportError PyErr_SetInterrupt=python35.PyErr_SetInterrupt PyErr_SetNone=py
Re: [Python-Dev] Keyword-only parameters
On Tue, Apr 14, 2015 at 1:06 PM, Steven D'Aprano wrote: > On Tue, Apr 14, 2015 at 01:40:40PM -0400, Eric V. Smith wrote: >> But, I don't see a lot of keyword-only parameters being added to stdlib >> code. Is there some position we've taken on this? Barring someone saying >> "stdlib APIs shouldn't contain keyword-only params", I'm inclined to >> make numeric_owner keyword-only. > > I expect that's because keyword-only parameters are quite recent (3.x > only) and most of the stdlib is quite old. > > Keyword-only feels right for this to me too. +1 -- Zach ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Issue #20172: Convert the winsound module to Argument Clinic.
On Wed, May 13, 2015 at 1:50 AM, Serhiy Storchaka wrote:
> On 13.05.15 09:32, zach.ware wrote:
>>
>> https://hg.python.org/cpython/rev/d3582826d24c
>> changeset: 96006:d3582826d24c
>> user:Zachary Ware
>> date:Wed May 13 01:21:21 2015 -0500
>> summary:
>>Issue #20172: Convert the winsound module to Argument Clinic.
>
>
>> +/*[clinic input]
>> +winsound.PlaySound
>> +
>> +sound: Py_UNICODE(nullable=True)
>
>
> I think this is no longer correct syntax. Should be Py_UNICODE(accept={str,
> NoneType}).
Oh, whoops. I forgot to run clinic over things again before committing.
We need to stick that into the Windows build process somewhere...
--
Zach
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Repository builds as 2.7.8+
On Wed, May 13, 2015 at 4:05 PM, Terry Reedy wrote: > Python 2.7.8+ (default, May 13 2015, 16:46:29) [MSC v.1500 32 bit (Intel)] > on win32 > > Shouldn't this be 2.7.9+ or 2.7.10rc1? Make sure your repository is up to date, the patchlevel is correct at the current tip of the 2.7 branch. -- Zach ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Clarifying Cygwin support in CPython
On Wed, Nov 8, 2017 at 8:39 AM, Erik Bray wrote: > a platform--in particular it's not clear when a buildbot is considered > "stable", or how to achieve that without getting necessary fixes > merged into the main branch in the first place. I think in this context, "stable" just means "keeps a connection to the buildbot master and doesn't blow up when told to build" :). As such, I'm ready to get you added to the fleet whenever you are. -- Zach ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] GH-NNNN vs #NNNN in merge commit
On Thu, Jan 25, 2018 at 12:03 PM, Mariatta Wijaya wrote: >> Of course, we would still need to convince people to install it :) > > > Right, that's the challenge :) > I personally use Chrome (!) and I've been using your Chrome extension, so > thank you! > However, I don't feel comfortable making this available only for a specific > browser user, feels exclusionary to me. > Also, sometimes I merge from my phone where there's no chrome extension, > (maybe I really shouldn't be doing that?). A large part of Brett's push for moving to a PR workflow was to be able to merge patches from a tablet on the beach, so I see no reason not to merge from a phone if you can :) > I think the solution should be something not webbrowser specific. > > One idea is maybe have a bot to do the squash commit, for example by > commenting on GitHub: > @merge-bot merge > > So core devs can do the above instead of pressing the commit button. Any > thoughts on this? > > In the meantime, committers, please try to remember and change the # into > GH- :) +1 to everything here. -- Zach ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Is 4.0 a major breaking changes release?
On Sat, Feb 3, 2018 at 4:40 PM, Alex Walters wrote: > I am still working on porting code from 2.x to 3.x. As of late on the lists > I've seen comments about making somewhat major changes in 4.0 - now I'm > concerned that I should pause my porting effort until that is released. Is > python 4 going to be another python 3? Emphatically no. Anyone suggesting big breaking changes in 4.0 is exercising wishful thinking :) There may be some cleanup in 4.0, but only removing things that have been deprecated for a long time in 3.x but hadn't been removed to maintain compatibility with 2.7. -- Zach ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Basic test to validate win10 install?
Hi Martin, On Mon, Apr 16, 2018 at 5:00 PM, Martin Gainty wrote: > I was told the python -m test are for devs only to test "auxiliary > functions" > do you have a "basic test" i can use to validate Python36 has installed > properly on Win10? The fact that the tests run at all show that everything installed properly. The three failures that you see don't look serious, and are probably only failing due to differences in the development and installation environments on Windows. One of these days I hope to have a bulidbot that automatically installs and tests Python on every commit on Windows, but we're not there yet. Until then, investigating these failures and contributing patches to fix them could be a great way to get involved in CPython development! Regards, -- Zach ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Windows 10 build agent failures
On Sun, May 6, 2018 at 3:05 AM, Paul Goins wrote: > Hi, > > Just kind of "looking around" at stuff I can help with, and I noticed a few > days ago that Windows 10 AMD64 builds of Python 3.6/3.7/3.x are generally > failing. > > It seems like the failures started April 16th around 1am per BuildBot and > went from consistently passing to consistently failing. The errors appear > to be timeouts; the test runs are going over 15 minutes. > > I can run the tests locally and things seem fine. > > The one thing which seems to have changed is, under the "10 slowest tests" > header, test_io has shot up in terms of time to complete: > > 3.6: 2 min 13 sec to 9 min 25 sec > 3.7: 2 min 10 sec to 9 min 26 sec > 3.x: 3 min 39 sec to 9 min 17 sec > > Locally this test suite runs in around 36 seconds. I see no real change > between running one of the last "good" changesets versus the current head of > master. I'm suspecting an issue on the build agent perhaps? Thoughts? We have an open issue for this at https://bugs.python.org/issue33355. -- Zach ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] please help triage VSTS failures
On Fri, May 18, 2018 at 10:55 AM, Gregory P. Smith wrote: > These both look like VSTS infrastructure falling over on PRs: > > https://python.visualstudio.com/cpython/_build?buildId=522 > > https://python.visualstudio.com/cpython/_build?buildId=523 > > I don't see anywhere that gives information about the failures. (*) Somewhat non-intuitively, logs are available by clicking something in the tree in the left column (in particular, the inner-most thing with a red X). Do be sure to choose "Logs" in the right pane rather than "Tests"; "Tests" appears to be a separate feature that we don't use. > These CI failures on different platforms are both for the same change, on > different branches, for a documentation only change. That passed on the > other branches and platforms for the same change. The Windows failure appears to be the test_asyncio instability that has been popping up everywhere the past couple of days. The Linux failure looks like a mis-use of Tools/ssl/multissltests.py in the setup, but I thought I'd seen a checkin go by that removed that. -- Zach ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Keeping an eye on Travis CI, AppVeyor and buildbots: revert on regression
On Wed, Jun 6, 2018 at 9:45 PM, Mariatta Wijaya wrote: > Are there APIs we can use to check the status of builbots? > Maybe we can have the our bots check for the buildbot status in backport > PRs. There is a REST API for buildbot; I have no idea how usable/useful it is though (but I think the new UI interacts with the master mostly via REST calls). I am planning to eventually get buildbot integration with GitHub set up, possibly in September. I think it should be possible to make only stable bots show up as status checks, or even just a select subset of the stable bots. -- Zach ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] We now have C code coverage!
On Sat, Jun 23, 2018 at 11:31 AM, Terry Reedy wrote: > I have suggested that, and before that, the same for buildbots. The reality > is that tkinter, IDLE, or turtle could be disabled on *nix by regressions > and the official testing would not notice. I'm looking into enabling the GUI tests on some of the CI hosts today, not sure how far I'll make it with that. GUI tests are currently enabled on my Gentoo [1] and Windows [2] builders, and have been for a couple of years at this point; I'm not sure if any other builders are running GUI tests. [1] http://buildbot.python.org/all/#/workers/6 [2] http://buildbot.python.org/all/#/workers/11 -- Zach ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] We now have C code coverage!
On Sat, Jun 23, 2018 at 2:20 PM, Terry Reedy wrote:
> Rechecking now, on Gentoo
>
> test_idle appears and passed on these 3.6 and 3.7 pages
> http://buildbot.python.org/all/#/builders/82/builds/414/steps/5/logs/stdio
>
> Neither Firefox nor Edge can find 'test_idle' on these 3.x pages
> http://buildbot.python.org/all/#/builders/103/builds/1149/steps/5/logs/stdio
> http://buildbot.python.org/all/#/builders/99/builds/1130/steps/4/logs/stdio
>
> test_tk appears on 1130 but not 1149
>
> For your 8.1 bot: test_idle passed for 3.7
> http://buildbot.python.org/all/#/builders/133/builds/339/steps/3/logs/stdio
>
> but does is not found on this 3.x page (neither is 'test_tk')
> http://buildbot.python.org/all/#/builders/12/builds/991/steps/3/logs/stdio
Click the magnifying glass icon ("load all data for use with the
browser search tool") at the upper right of the console pane and try
again; each of the above is present and passed. This does
unfortunately seem to be another case of non-intuitive UI from
buildbot.
> Both Appveyor and my machine run test_idle when running the full 3.x test
> suite.
I am pleasantly surprised that AppVeyor does appear to be running the
GUI tests :)
--
Zach
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Can someone configure the buildbots to build the 3.5 branch?
On Thu, May 28, 2015 at 6:59 PM, Larry Hastings wrote: > The buildbots currently live in a state of denial about the 3.5 branch. > Could someone whisper tenderly in their collective shell-like ears so that > they start building 3.5, in addition to 3.4 and trunk? The 3.5 branch seems to be set up on the buildbots, we'll see how it goes when somebody commits something to 3.5. -- Zach ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Backporting the 3.5+ Windows build project files to 2.7
Hi, As you may know, Steve Dower put significant effort into rewriting the project files used by the Windows build as part of moving to VC14 as the official compiler for Python 3.5. Compared to the project files for 3.4 (and older), the new project files are smaller, cleaner, simpler, more easily extensible, and in some cases quite a bit more correct. I'd like to backport those new project files to 2.7, and Intel is willing to fund that work as part of making Python ICC compilable on all platforms they support since it makes building Python 2.7 with ICC much easier. I have no intention of changing the version of MSVC used for official 2.7 builds, it *will* remain at MSVC 9.0 (VS 2008) as determined the last time we had a thread about it. VS 2010 and newer can access older compilers (back to 2008) as a 'PlatformToolset' if they're installed, so all we have to do is set the PlatformToolset in the projects at 'v90'. Backporting the projects would make it easier to build 2.7 with a newer compiler, but that's already possible if somebody wants to put enough work into it, the default will be the old compiler, and we can emit big scary warnings if somebody does use a compiler other than v90. With the stipulation that the officially supported compiler won't change, I want to make sure there's no major opposition to replacing the old project files in PCbuild. The old files would move to PC\VS9.0, so they'll still be available and usable if necessary. Using the backported project files to build 2.7 would require two versions of Visual Studio to be installed; VS2010 (or newer) would be required in addition to VS2008. All Windows core developers should already have VS2010 for Python 3.4 (and/or VS2015 for 3.5) and I expect that anyone else who cares enough to still have VS2008 probably has (or can easily get) one of the free editions of VS 2010 or newer, so I don't consider this to be a major issue. The backported files could be added alongside the old files in PCbuild, in a better-named 'NewPCbuild' directory, or in a subdirectory of PC. I would rather replace the old project files in PCbuild, though; I'd like for the backported files to be the recommended way to build, complete with support from PCbuild/build.bat which would make the new project files the default for the buildbots. I have a work-in-progress branch with the backported files in PCbuild, which you can find at https://hg.python.org/sandbox/zware/log/project_files_backport. There are still a couple bugs to work out (and a couple unrelated changes to PC/pyconfig.h), but most everything works as expected. Looking forward to hearing others' opinions, -- Zach ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Backporting the 3.5+ Windows build project files to 2.7
On Mon, Jun 22, 2015 at 5:20 PM, Steve Dower wrote: > Zachary Ware wrote: >> With the stipulation that the officially supported compiler won't change, I >> want >> to make sure there's no major opposition to replacing the old project files >> in >> PCbuild. The old files would move to PC\VS9.0, so they'll still be available >> and >> usable if necessary. > > I'm selfishly -0, since this won't benefit me and will give me more work (I > don't develop 2.7 other than to build the releases, so this will just cause > me to mess with my build machine). But since other people are doing most of > the work I'm not going to try and block it. I will be making sure that the files in PC\VS9.0 do still work properly; I could also try to adjust paths in Tools\msi such that you would only need to use PC\VS9.0 instead of PCbuild. I have yet to successfully build an MSI for any Python release, though, so I can't make any promises about that working. > I don't see any real need to emit scary warnings about compiler compatibility > - a simple warning like in 3.5 for old compilers is fine. That's the one I was talking about, actually :). Describing it as a "big scary" warning was probably a bit much. >> Using the backported project files to build 2.7 would require two versions of >> Visual Studio to be installed; VS2010 (or newer) would be required in >> addition >> to VS2008. All Windows core developers should already have VS2010 for Python >> 3.4 >> (and/or VS2015 for 3.5) and I expect that anyone else who cares enough to >> still >> have VS2008 probably has (or can easily get) one of the free editions of VS >> 2010 >> or newer, so I don't consider this to be a major issue. > > It may have a workaround, but it also could be a serious blocking issue for > those who can't install another version. Especially since there's no benefit > to the resulting builds. The easiest workaround would be to use the project files in PC\VS9.0. It might work to install only whatever gets you a new-enough MSBuild, but I haven't tested that at all and thus don't know. I will tell you that it works to build the backported pcbuild.proj with \Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe, invoked from a clean environment on a machine with VS 2008, 2010, 2013, and 2015RC installed, though. >> The backported files could be added alongside the old files in PCbuild, in a >> better-named 'NewPCbuild' directory, or in a subdirectory of PC. I would >> rather >> replace the old project files in PCbuild, though; I'd like for the backported >> files to be the recommended way to build, complete with support from >> PCbuild/build.bat which would make the new project files the default for the >> buildbots. > > Agreed, just replace them. PCBuild is messy enough with the output files in > there (I'd avoid moving them - plenty of the stdlib and test suite expects > them to be there), we don't need duplicate project files. That probably explains a few of the failures I'm still seeing that I hadn't dug into yet. -- Zach ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Backporting the 3.5+ Windows build project files to 2.7
On Mon, Jun 22, 2015 at 6:29 PM, Chris Barker - NOAA Federal wrote: >> I'd like to backport those new project files to 2.7, > > Would this change anything about how extensions are built? > > There is now the "ms compiler for 2.7" would that work? Or only in > concert with VS2010 express? It should have absolutely no impact on building extensions. If it does, that's a bug to be fixed. Regular users of Python on Windows (those who don't build their own) should have no idea that anything has changed at all. -- Zach ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] speed.python.org (was: 2.7 is here until 2020, please don't call it a waste.)
On Thu, Jun 4, 2015 at 10:51 AM, Maciej Fijalkowski wrote: > On Thu, Jun 4, 2015 at 4:32 PM, R. David Murray wrote: >> OK, so what you are saying is that speed.python.org will run a buildbot >> slave so that when a change is committed to cPython, a speed run will be >> triggered? Is "the runner" a normal buildbot slave, or something >> custom? In the normal case the master controls what the slave >> runs...but regardless, you'll need to let us know how the slave >> invocation needs to be configured on the master. > > Ideally nightly (benchmarks take a while). The setup for pypy looks like this: > > > https://bitbucket.org/pypy/buildbot/src/5fa1f1a4990f842dfbee416c4c2e2f6f75d451c4/bot2/pypybuildbot/builds.py?at=default#cl-734 > > so fairly easy. This already generates a json file that you can plot. > We can setup an upload automatically too. I've been looking at what it will take to set up the buildmaster for this, and it looks like it's just a matter of checking out the benchmarks, building Python, testing it, and running the benchmarks. There is the question of which benchmark repo to use: https://bitbucket.org/pypy/benchmarks or https://hg.python.org/benchmarks; ideally, we should use hg.python.org/benchmarks for CPython benchmarks, but it looks like pypy/benchmarks has the necessary runner, so I suppose we'll be using it for now. Is there interest from both sides to merge those repositories? The big question for the buildmaster is what options to pass to the benchmark runner. I suppose most of them should match the CPythonBenchmark BuildFactory from the PyPy buildbot master configuration, but otherwise I'm not sure. The other big question is where the benchmarks will be run. The speed.python.org page makes it sound like there's a box intended for that purpose (the one running the speed.python.org page?); can anyone with access to it contact me to get the build slave set up? -- Zach ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Backporting the 3.5+ Windows build project files to 2.7
On Mon, Jun 22, 2015 at 10:37 PM, Nick Coghlan wrote: > I'd suggest explicitly reaching out to the Stackless folks to get > their feedback. As I believe the switched to a newer compiler and VC > runtime for Windows a while back, I suspect it will make their lives > easier rather than harder, but it's still worth asking for their > input. >From a glance at the stackless repo, it looks like it still uses VS2008's project files (which pretty much means using MSVC 9), but I could have easily missed something. Christian, what say you? Would having the project files from 3.5 backported to 2.7 (but still using MSVC 9) be positive, negative, or indifferent for Stackless? -- Zach ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Backporting the 3.5+ Windows build project files to 2.7
On Jun 23, 2015, at 06:27, Christian Tismer wrote: > On 23.06.15 06:42, Zachary Ware wrote: >> Christian, what say you? Would having the project files from 3.5 >> backported to 2.7 (but still using MSVC 9) be positive, negative, or >> indifferent for Stackless? > > I am very positive about your efforts. > > We wanted to create a Stackless 2.8 version end of 2013 > with support for newer compilers, to begin with. After a while, > we stopped this, and I left the branch in a private, unmaintained > repository. > https://bitbucket.org/stackless-dev/stackless-private/branch/2.8-slp Thanks, Chris! Since there has been no violent opposition (and some positive support), I’ve cleaned up the patch and posted it: https://bugs.python.org/issue24508 Reviews (and review-by-testing) welcome! -- Zach ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Backporting the 3.5+ Windows build project files to 2.7
On Thu, Jun 25, 2015 at 8:54 AM, M.-A. Lemburg wrote: > On 22.06.2015 19:03, Zachary Ware wrote: >> Using the backported project files to build 2.7 would require two >> versions of Visual Studio to be installed; VS2010 (or newer) would be >> required in addition to VS2008. All Windows core developers should >> already have VS2010 for Python 3.4 (and/or VS2015 for 3.5) and I >> expect that anyone else who cares enough to still have VS2008 probably >> has (or can easily get) one of the free editions of VS 2010 or newer, >> so I don't consider this to be a major issue. > > To understand this correctly: > > In order to build Python 2.7.11 (or a later version), we'd > now need VS 2008 *and* VS 2010 installed ? Using the backported project files, yes, two versions of VS would be required. However, the second version doesn't have to be VS 2010, it could be 2010, 2012, 2013, 2015, or any from the future (until Microsoft changes the format of the project files again). > This doesn't sound like it would make things easier for > people who need to build their own Python on Windows, e.g. > because they are freezing their apps for distribution, or > using their own internal special builds. > > For VS 2008 we now have a long-term solution thanks to MS. > The same is not true for VS 2010 (download links are not official > anymore), so we'd complicate things again by requiring the > mixed compiler setup. For anyone building 2.7 and any other (current) version of Python on the same machine, all the necessary pieces are already in place. The main motivation for backporting is to make it easier to build Python with ICC. Pre-backport, Intel gave me a list of 9 steps they were doing to build 2.7.10 with ICC. Post-backport, it's just `PCbuild\build.bat -e [-p x64] [-d] "/p:PlatformToolset=Intel C++ Compiler XE 15.0" "/p:BasePlatformToolset=v90"` (the bracketed options being optional, for 64-bit and debug builds, respectively). There are some benefits for MSVC builds too, though: it's easier to do a parallel build, and OpenSSL and Tcl/Tk/Tix are built by the project files, so the whole build can be done much quicker. The new project files for Tcl and Tk also take care of copying their DLLs into PCbuild so that _tkinter can find them without having to mess around with PATH. My patch also fixes a couple of long-standing bugs with finding the right libraries for 64-bit Tcl/Tk and the test suite undoing the work of FixTk.py after any test that imports Tkinter, both of which were exacerbated by the rest of the patch. > If you keep the old VS 2008 build files around, I'd be > fine with having an optional upgrade path to newer > compilers :-) The old files are moved to PC/VS9.0, and they work as expected as far as I've tested them. Btw, the upgrade path to newer compilers is just a side-effect which I'm kind of torn about. On one hand, making it easier to build 2.7 with the "wrong" compiler is bound to lead to issues somewhere somehow. On the other hand, people are already doing so anyway, with their own upgraded project files. > It's rather unlikely that the project files will change much > in coming years, so there shouldn't be much maintenance > effort. Hopefully not :) -- Zach ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Backporting the 3.5+ Windows build project files to 2.7
On Thu, Jun 25, 2015 at 1:48 PM, M.-A. Lemburg wrote: > On 25.06.2015 17:12, Zachary Ware wrote: >> The old files are moved to PC/VS9.0, and they work as expected as far >> as I've tested them. > > So it's still possible to build with "just" VS 2008 installed > or will the VS 2010 (or later) be required for those old > files as well ? Only VS 2008 is required for the old files. Building in PC/VS9.0/ post-backport is exactly the same as building in PCbuild/ pre-backport. > I guess will have the discussion about switching compilers > for Python 2.7 again at some point. People writing extensions > will sooner or later want to use features from more recent > compilers for Python 2.7 as well :-) I expect the same outcome every time it comes up --- too much breakage for not enough benefit :) -- Zach ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Backporting the 3.5+ Windows build project files to 2.7
On Thu, Jun 25, 2015 at 10:42 AM, Steve Dower wrote: > This also makes it more viable to use the Windows SDK compilers. If you > install the Windows SDK 7.0 (which includes MSVC9) and Windows SDK 7.1 (which > includes the platform toolset files for MSVC9 - toolsets were invented later > than the 7.0 release) then you should be able to build from the command line > or any version of Visual Studio from 2010 onwards. I suspected this, but hadn't brought it up because I hadn't looked into it in depth. This sounds good though! The SDKs are supported quite a bit longer than VS versions, aren't they? -- Zach ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Tighten-up code in the set iterator to use an entry pointer rather than
On Tue, Jul 7, 2015 at 2:03 PM, Ethan Furman wrote: > On 07/07/2015 08:15 AM, Serhiy Storchaka wrote: >> This will make harder to notice (and fix!) other regressions. > > I don't understand what you are trying to say. If a bug is worth fixing, > it's worth having a test so we don't have to fix it again in the future. I believe Serhiy's point is that there's no need to commit the test before the fix, so that the buildbots won't be unnecessarily red until the fix is committed. The fix should, of course, include a test. -- Zach ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Tighten-up code in the set iterator to use an entry pointer rather than
On Tue, Jul 7, 2015 at 3:16 PM, Brett Cannon wrote: > The test could be marked as an expected failure in the interim somitnisnt > forgotten. True, but in this case things would be a bit more difficult since the testcase segfaults rather than just throwing an exception. -- Zach ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Building python 2.7.10 for Windows from source
On Jul 24, 2015 8:30 AM, "Mark Kelley" wrote: > > I have been using Python for some time but it's been a decade since > I've tried to build it from source, back in the 2.4 days. Things seem > to have gotten a little more complicated now. > > I've read through the PCBuild/README file and got most stuff > compiling. I find it a little odd that there are special instructions > for the building the release version of tcl/tk. Is that what the > developers actually do when they cut a release, or is there some > other, top-level script that does this automatically? It just seems > odd. That used to be standard procedure, yes. However, I just recently backported the project files from 3.5, which include project files for building Tcl/Tk and Tix, in both Debug and Release configurations, so I may have missed some stuff that could be removed from PCbuild/readme.txt. You do need some extra stuff to build 2.7 with its new project files, though (which i know is now covered in readme.txt). There hasn't been a release with those project files yet though, they're just in the hg repo. > Anyhow, my specific question is around the distutils wininst stubs, > provided as binaries in the release tarball. Where can I find the > source files that those binaries are built from? I believe the source for those is in PC/bdist_wininst/, or some very similar path. Hope this helps, -- Zach (On a phone) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issues not responded to.
On Thu, Jul 30, 2015 at 8:21 PM, Brett Cannon wrote: > Best thing I can think of is to post the Roundup search you did to find > those 400 so thoseof us who can help can just start whittling them away. You > could also share it with core-mentorship and explain we need help evaluating > these issues with the caveat we have no idea how difficult it is to do the > evaluation. Here's a query: https://bugs.python.org/issue?@action=search&@columns=title,id,creator,activity,actor,status&@sort=activity&status=-1,1,3,4&message_count=1 -- Zach ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Differences between Python's OpenSSL in SVN and OpenSSL's in GitHub
On Fri, Aug 14, 2015 at 10:56 AM, Guzman-ballen, Andres
wrote:
> Hello Python Developers!
>
> Why is it that the OpenSSL v1.0.2d that is found on Python’s SVN repo is
> quite different from what OpenSSL has on their GitHub repository for OpenSSL
> v1.0.2d?
The reason for the difference is to avoid requiring Perl to be
installed to be able to build Python. The svn.python.org version of
openssl-1.0.2d at revision 89058should match 1.0.2d from Github (if it
doesn't that's a bug in OpenSSL's packaging or my checking it into
SVN). Revision 89059 checks in all of the changes, all of which are
made by running 'PCbuild\prepare_ssl.py' on the vanilla sources, and
you should be able to produce the same set of changes by running
'PCbuild\prepare_ssl.py' over the sources checked out from Github.
Note that to run that script successfully, you'll need to have the
Visual Studio environment set up ('PCbuild\env.bat' will do it for
you), Perl and NASM on your PATH, and run the script with Python 3.4
or later.
Hope this answers your question,
--
Zach
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Testing tkinter on Linux
On Thu, Aug 27, 2015 at 4:13 PM, Chris Angelico wrote: > On Fri, Aug 28, 2015 at 5:00 AM, R. David Murray > wrote: >> I believe gui depends on the existence of the DISPLAY environment >> variable on unix/linux (that is, TK will fail to start if DISPLAY is not >> set, so _is_gui_available will return False). You should be able to >> confirm this by looking at the text of the skip message in the buildbot >> output. > > A recent buildbot log [1] shows that the GUI tests are being skipped, > although I'm not seeing the message. Where do I go to set DISPLAY for > the bot (which runs mostly in the background)? > > Note that it's all running as root, which may make a difference to the > defaults, so this might have to be done more explicitly than it > otherwise would. (But root is quite happy to use X; running xclock > brings up a clock just fine.) I just set up a buildslave building with X available [1]. I don't know if the way I did it is strictly correct, but my slave is set up with Xvfb set to start at boot, and I hacked the buildbot.tac file to add 'os.environ["DISPLAY"] = ":100"' (which is what Xvfb starts on) as that was the simplest way I could figure out to do it. It seems to work; an initial test build of 2.7 passed all the Tcl/Tk tests [2]. For those interested, the slave has Tcl/Tk 8.5.17 installed (which is the latest "stable" release in portage). [1] http://buildbot.python.org/all/buildslaves/ware-gentoo-x86 [2] http://buildbot.python.org/all/builders/x86%20Gentoo%20Non-Debug%20with%20X%202.7/builds/0/steps/test/logs/stdio -- Zach ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Request a builedbot username and password
On Thu, Sep 3, 2015 at 2:15 AM, Zhuo Chen wrote: > Hi I am interested in setting up a builedbot machine for python, I have a > 2011 MacBook Pro with custom ssd and OS X Yosemite Responding off-list. -- Zach ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Rationale behind lazy map/filter
On Tue, Oct 13, 2015 at 10:26 AM, Random832 wrote: > "R. David Murray" writes: > >> On Tue, 13 Oct 2015 14:59:56 +0300, Stefan Mihaila >> wrote: >>> Maybe it's just python2 habits, but I assume I'm not the only one >>> carelessly thinking that "iterating over an input a second time will >>> result in the same thing as the first time (or raise an error)". >> >> This is the way iterators have always worked. > > It does raise the question though of what working code it would actually > break to have "exhausted" iterators raise an error if you try to iterate > them again rather than silently yield no items. You mean like this? >>> m = map(int, '1234') >>> list(m) [1, 2, 3, 4] >>> next(m) Traceback (most recent call last): File "", line 1, in StopIteration It just happens that 'list()' and 'for ...' handle StopIteration for you. -- Zach ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] doc tests failing
On Fri, Nov 13, 2015 at 9:12 AM, Ethan Furman wrote: > What am I doing wrong? Expecting it to work :) `make doctest` is a Sphinx feature, not specific to our docs. Ideally someday it should work (and I'll add it to the Docs buildbot), but nobody has tried to make it work yet. Making it work might be a good large-ish project for newer contributors. -- Zach ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Benchmark results across all major Python implementations
On Mon, Nov 16, 2015 at 3:38 PM, Brian Curtin wrote:
> On Monday, November 16, 2015, Brett Cannon wrote:
>>>
>>> Hi Brett
>>>
>>> Any thoughts on improving the benchmark set (I think all of
>>> {cpython,pypy,pyston} introduced new benchmarks to the set).
>>
>>
>> We should probably start a mailing list
>
>
> There is/was a sp...@python.org list.
Is, but seems to be heavily moderated without active moderation. I
sent an offer to speed-owner this morning to help with moderation, but
as yet no response. I know I have a couple of messages waiting in the
queue :)
On Mon, 16 Nov 2015 at 12:24 Maciej Fijalkowski wrote:
> "speed.python.org" becoming a thing is generally stopped on "noone
> cares enough to set it up".
Setup is done in my dev environment, it's now blocking on people more
qualified than me to review and merge, then final tweaking of the
buildbot setup. For those interested:
The part in most need of review is the changes to the PSF Salt
configuration to set up and run Codespeed on speed.python.org. The
changes can be found in PR #74 on the psf-salt Github repo[0].
The Codespeed instance is housed in a Github repo owned by me[1]
currently. There's one small patch to the codespeed code (which was
merged upstream this morning), the rest of the changes in my fork are
adapting a copy of the sample_project to be our own instance. I've
been told that the grant proposal from long ago expected the use of
codespeed2 instead of codespeed. I chose codespeed over codespeed2
because it appeared to be easier to get set up and running (which may
or may not have actually been true), but also because I've not seen
codespeed2 in action anywhere.
The final piece that could use review is the changes to our benchmark
repository, currently available in a sandbox repo on hg.python.org[2].
My original plan had been to use PyPy's benchmark suite, but as you
can tell from the logs of the existing buildslave, cpython doesn't run
that suite especially well, and the cpython suite has the advantage of
working with Python 2 and 3 out of the box.
Please have a look, give it a try if you can, and let me know what
needs improvement!
[0] https://github.com/python/psf-salt/pull/74
[1] https://github.com/zware/codespeed
[2] https://hg.python.org/sandbox/zware-benchmarks
--
Zach
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Building with VS2015
On Tue, Jan 12, 2016 at 9:32 PM, Alexander Walters wrote: > This is a mailing list for the development of python itself, not support for > building it. That said... > > 3.4 uses visual studio 2010, for starters. 3.5 uses 2015. Agreed with all of the above. You'll be much happier using either 3.5 with VS 2015, or 3.4 with VS 2010. You might coerce things the other way around, but you won't get official support for it and you won't match the rest of the world (in particular, binary packages from PyPI won't work). > It also looks like you have a lot of missing dependencies. Run `PCbuild\get_externals.bat` after installing Subversion (and ensuring that svn.exe is on PATH) to resolve the missing dependencies. The other errors will require patching the source, and it's too late in the 3.4 release cycle for those patches to be accepted for 3.4.5. I also find it much simpler to use `PCbuild\build.bat` instead of building from the VS GUI. A 32bit Release build with all the optional pieces can be accomplished with `PCbuild\build.bat -e`; add '-p x64' for a 64bit build. -- Zach ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Update PEP 7 to require curly braces in C
On Thu, Jan 21, 2016 at 11:12 AM, Brett Cannon wrote: > On Wed, 20 Jan 2016 at 23:07 Nick Coghlan wrote: >> - I wasn't aware of that >> requirement, so I've never explicitly checked CLA status for folks >> contributing packaging related PEPs. (And looking at the >> just-checked-in PEP 513, I apparently have a CLA to chase up...) > > Yeah, I didn't know either until I asked Van, so I think it's new to > everyone. :) It's quite surprising to me, since all (as far as I know) PEPs are explicitly public domain. I am very much not a lawyer, though :) -- Zach ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Buildbot timing out - test suite failure - test_socket issue with UDP6?
On Sat, Jan 23, 2016 at 12:03 AM, Chris Angelico wrote: > By the way, this looks odd: > > make buildbottest TESTOPTS= TESTPYTHONOPTS= TESTTIMEOUT=3600 > in dir /root/buildarea/3.x.angelico-debian-amd64/build (timeout 3900 secs) > > The parameter says 3600 (which corresponds to the error message at the > end), but it echoes back that the timeout is 3900 seconds. I'm no help on the main issue, but to explain the timeout difference: TESTTIMEOUT is a makefile variable that sets the faulthandler timeout that tries to make Python bail out with a stack trace instead of letting buildbot kill Python silently. The 3900 second timeout is buildbot's "there's been no output in this long, assume it's hung and kill it" timeout. The difference between the two is to give faulthandler a chance to do its thing. -- Zach ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] speed.python.org
I'm happy to announce that speed.python.org is finally functional! There's not much there yet, as each benchmark builder has only sent one result so far (and one of those involved a bit of cheating on my part), but it's there. There are likely to be rough edges that still need smoothing out. When you find them, please report them at https://github.com/zware/codespeed/issues or on the sp...@python.org mailing list. Many thanks to Intel for funding the work to get it set up and to Brett Cannon and Benjamin Peterson for their reviews. Happy benchmarking, -- Zach ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] speed.python.org
On Mon, Feb 8, 2016 at 1:09 PM, Yury Selivanov wrote: > Zachary, > > Do you run the benchmarks in rigorous mode? Not currently. I think I need to reschedule when the benchmarks are run anyway, to avoid conflicts with PyPy's usage of that box, and will add rigorous mode when I do that. -- Zach ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] When should pathlib stop being provisional?
On Thu, Apr 7, 2016 at 5:50 AM, Michel Desmoulin
wrote:
> Path objects don't have splitext() or and don't allow "string" / path.
> Those are the ones bugging me the most.
>>> import pathlib
>>> p = '/some/test' / pathlib.Path('path') / 'file_with.ext'
>>> p
PosixPath('/some/test/path/file_with.ext')
>>> p.parent, p.stem, p.suffix
(PosixPath('/some/test/path'), 'file_with', '.ext')
--
Zach
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()
On Mon, Apr 11, 2016 at 11:18 AM, Ethan Furman wrote: > If those examples are anywhere close to accurate, an fspath protocol that > supported both bytes and str seems a lot easier to work with. But why are you working with bytes paths in the first place? Where did you get them from, and why couldn't you decode them at that boundary? In 7ish years of working with Python (almost exclusively Python 3) on Windows and UNIX, I have never used bytes paths on any platform. -- Zach ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Most 3.x buildbots are green again, please don't break them and watch them!
On Wed, Apr 13, 2016 at 6:40 AM, Victor Stinner wrote: > Hi, > > Last months, most 3.x buildbots failed randomly. Some of them were > always failing. I spent some time to fix almost all Windows and Linux > buildbots. There were a lot of different issues. Thank you for doing this! > Maybe it's time to move more 3.x buildbots to the "stable" category? > http://buildbot.python.org/all/waterfall?category=3.x.stable A few months ago, I put together a list of suggestions for updating the stable/unstable list, but never got around to implementing it. > We have many offline buildbots. What's the status of these buildbots? > Should we expect that they come back soon? My Windows 8.1 bot is a VM that resides on a machine that has been disturbingly unstable lately, and it's starting to seem like the instability is due to that VM. I hope to have it back up (and stable) again soon, but have no timetable for it. My Docs bot was off after losing power over the weekend, and I just hadn't noticed yet. It's back now. I'll ping the python-buildbots list about other offline bots. > Or would it be possible to hide them? It would help to check the > status of all buildbots. I'm not sure, but that would be a nice feature. > - the 4 ICC buildbots are failing with stack overflow, segfault, etc. > Again, I'm not sure that these buildbots are useful since it looks > like we don't support this compiler yet. Or does it help to work on > supporting this compiler? Who is working on ICC support? The Ubuntu ICC bot is generally quite stable. The OSX ICC bot is currently offline, but has only a couple of known issues. The Windows ICC bot is still a bit experimental, but has inched closer to producing a working build. R. David Murray and I have been working with Intel on ICC support. > By the way, I'm always surprised by the huge difference of time needed > to run a build on the different slaves: from a few minutes to more > than 3 hours. The fatest Windows slave takes 28 minutes (run tests in > parallel using 4 child processes), whereas the 3 others (run tests > sequentially and) take between 2 hours and more than 3 hours! Why > running tests on Windows takes so long? Most of that is down to debug mode; building Python in debug mode links with the debug CRT which also enables all manner of extra checks. When it's up, the non-debug Windows bot also runs the test suite in ~28 minutes, running sequentially. --- After receiving a suggestion from koobs several months ago, I've been intermittently thinking about completely redoing our buildmaster setup such that instead of a single builder per version on each slave, we instead set up a series of builders with particular 'tags', and each builder attaches to each slave that satisfies the tags (running each build only on the first slave available). This would allow us to test some of the rarer options (such as --without-threads) significantly more often than 'never', and generally get a lot more customization/flexibility of builds. I haven't had a chance to sit down and think out all the edge cases of this idea, but what do people generally think of it? I think the GitHub switchover will be a good time to do this if it's generally seen as a decent idea, since there will need to be some work on the buildmaster to do the switch anyway. -- Zach ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Tag-based buildmaster (was: Most 3.x buildbots are green again ... )
(Cross-posting to python-buildbots, discussion is probably best continued there) On Wed, Apr 13, 2016 at 3:37 PM, Brett Cannon wrote: > On Wed, 13 Apr 2016 at 13:17 Zachary Ware > wrote: >> After receiving a suggestion from koobs several months ago, I've been >> intermittently thinking about completely redoing our buildmaster setup >> such that instead of a single builder per version on each slave, we >> instead set up a series of builders with particular 'tags', and each >> builder attaches to each slave that satisfies the tags (running each >> build only on the first slave available). This would allow us to test >> some of the rarer options (such as --without-threads) significantly >> more often than 'never', and generally get a lot more >> customization/flexibility of builds. I haven't had a chance to sit >> down and think out all the edge cases of this idea, but what do people >> generally think of it? I think the GitHub switchover will be a good >> time to do this if it's generally seen as a decent idea, since there >> will need to be some work on the buildmaster to do the switch anyway. > > So we have slaves connect to multiple builders who have requirements of what > they are testing? So the --without-threads master would have all slaves able > to compile --without-threads connect to it and then do that build? And those > same slaves may also connect to the gcc and clang masters to do those builds > as well? So would that mean slaves could potentially do a bunch of builds > per change? That sounds nice to me as long as the slave maintainers are also > up to utilizing this by double/triple/quadrupling their builds. Basically, yes. I'm unsure as to whether the build would be done on all matching slaves on each change, or rotate between them (or use the next available) on each change; that would likely come down to which scheme we collectively want. I also have vague ideas about having 'daily' or even 'weekly' tags for builds that are deemed to not need a build for every changeset, which could alleviate some of the multiplying. -- Zach ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Terminal console
On Apr 25, 2016 17:08, "Brett Cannon" wrote: > > Good point. Hopefully that's all it was then. Is there any particular reason we include that link in python-dev emails? We don't for any other list as far as I know. -- Zach (On a phone) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Terminal console
On Apr 26, 2016 07:45, "Franklin? Lee" wrote: > > On Apr 26, 2016 4:02 AM, "Paul Moore" wrote: > > > > On 25 April 2016 at 23:55, Franklin? Lee wrote: > > > FWIW, Gmail's policies require: > > [...] > > > That link is currently the only obvious way to unsubscribe. > > > > I'm not sure why gmail's policies should apply to this list. > > They're Gmail's policies on how not to get your messages filtered by Gmail as spam. > > I am not clear on whether they're descriptive (i.e. users will mark you as spam) or prescriptive (i.e. Google's algorithms will determine that you're spam). I have no trouble with Gmail with several other Python lists that do not include an unsubscribe link. -- Zach (On a phone) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Needs to install python 3.4.4 in RHEL 6
Hi Nilesh, On Thu, Apr 28, 2016 at 7:00 AM, Nilesh Date wrote: > Hi team, > > I wanted to install python version 3.4.4 in my RHEL 6 system. > Can someone give installation process or any reference link from which I can > get required steps and download desire package. You have a couple of options. Option 1: use software collections [1]. As I vaguely understand it (having never used this myself), the rh-python34 package is supported by Red Hat, and is like any other package for the most part. Looking at that page it does look a bit more complex than option 2 to me, but I've built and installed Python several times over the past few years :) Option 2: compile and install yourself. At a minimum, you'll need a c compiler (gcc, icc, or clang are recommended), and development headers for any extension modules that you require (I'd recommend openssl-devel and readline-devel at the least). Then download the source [2], extract it, and run `cd Python-3.4.4 && ./configure && make profile-opt && make test && sudo make install`. That series of commands will give you python installed in `/usr/local/` that has been compiled with profile-guided optimization (PGO) and has passed the full Python test suite. If any but the last step fails, nothing will have changed on your system. [1] https://www.softwarecollections.org/en/scls/rhscl/rh-python34/ [2] https://www.python.org/downloads/source/ Hope this helps, -- Zach ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Daily reference leaks (30f33e6a04c1): sum=975756
On Fri, Oct 18, 2013 at 12:30 PM, Antoine Pitrou wrote: > > Is anyone looking into those leaks? > I suspect they might have to do with Serhiy's latest re changes in > add40e9f7cbe. > (just a barely educated guess, though) I have confirmed that and was working towards getting my findings posted when this message came in :). Specifically, the leak is somewhere in sub (I believe pattern_subx() in _sre.c), but I currently lack the skill to figure out where. -- Zach ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython (2.7): Issue #XXXXX: Fix test_idle so that idlelib test cases are actually run
On Sun, Nov 3, 2013 at 10:54 PM, Terry Reedy wrote: > On 11/3/2013 11:48 PM, terry.reedy wrote: >> >> http://hg.python.org/cpython/rev/cced7981ec4d >> changeset: 86908:cced7981ec4d >> branch: 2.7 >> user:Terry Jan Reedy >> date:Sun Nov 03 23:37:54 2013 -0500 >> summary: >>Issue #X: Fix test_idle so that idlelib test cases are actually run >> under test.regrtest on 2.7. > > > This message is the one included with the patch by Ned Daily. Because a > message *was* included (not normal), hg import committed the patch > immediately, without giving me a chance to edit the patch or message. As far > as I know, there is no way I could have edited the message after the commit. > If there was, let me know. hg commit has an "--amend" option that allows you to change the last (un-pushed) commit. Even if there aren't actually any changes to be committed, it will pop up a text editor with the commit message of the last commit already filled in, allowing you to change the message. Any time you `hg commit --amend`, it saves the original commit locally as a bundle in the .hg dir, so you can restore it if need be. I haven't tested it, but from a quick look at TortoiseHg Workbench's Commit screen, it looks like --amend can be done from the down arrow on the commit button, "Amend current revision". -- Zach ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Sort error in Misc/ACKS
On Mon, Dec 9, 2013 at 8:57 AM, Barry Warsaw wrote: > On Dec 09, 2013, at 04:00 PM, TaeWong wrote: > >>The name Jonas Wagner comes before Zachary Ware and Barry Warsaw. > > Maybe it's time to give up on trying to sort by last name, and just sort by > first character? > > No, this is not a bold attempt to jump higher up in the list. > -AABarry Hey, I'm far enough down the list already... More seriously, we do specify "rough alphabetical order[ing]"; there's no need to point out this kind of thing. (Although it might be worth it to change that to "no particular order" so that adding someone is as simple as `echo "Some Human" >> Misc/ACKS`. We could always run random.shuffle() on the current list so new additions don't look out of place ;) -- Zach ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Buildbot running Debian amd64 as root
On Mon, Dec 30, 2013 at 12:18 PM, Christian Heimes wrote: > Am 30.12.2013 15:02, schrieb Chris Angelico: >> On Tue, Dec 31, 2013 at 12:05 AM, Chris Angelico wrote: >>> On Sun, Dec 8, 2013 at 12:35 AM, Chris Angelico wrote: In another thread it was suggested that a new buildbot running as root would be of value. I've spun up a virtual machine running Debian Wheezy amd64, have installed buildbot from the repository (version 0.8.6p1), and am ready to have it join the farm. How do I go about doing this? >>> >>> Is there any interest in this build slave? I haven't heard back from >>> anyone as to where to go from here. >> >> Antoine's contacted me off-list and sorted out the details. Bruce the >> Aussie Buildbot is now in operation. (And yes, the hostname is >> 'bruce'.) >> >> Thanks Antoine! > > Thanks guys! > > The buildbot is missing some vital header files. Please run: > > # apt-get build-dep python3.3 > > to install all required dependencies. It looks like it compiled and ran the tests fine, except for two failures due to a lack of zlib. If zlib is a required dependency, the build process should die without it (or fall back to the version living in Modules/zlib), and needs to be fixed. If it is as optional as it seems to look, then it might be good to keep a buildbot that explicitly doesn't have all (or even any) of the optional dependencies and we should just fix the tests that expect zlib unconditionally. Perhaps not this buildbot, though, since it's the only one running as root. Either way, this buildbot's first and thus far only run has already shown up something that needs to be fixed ;) -- Zach ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Buildbot running Debian amd64 as root
On Mon, Dec 30, 2013 at 2:31 PM, Zachary Ware wrote: > and we should just fix the tests that expect zlib unconditionally. Both of which turned out to be trivial; the import of zlib was already guarded in both places, but one skip was checking the wrong name and the other just didn't try to skip, so I've fixed both. -- Zach ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: add unicode_char() in unicodeobject.c to factorize code
On Fri, Jan 3, 2014 at 6:01 AM, victor.stinner
wrote:
> http://hg.python.org/cpython/rev/d453c95def31
> changeset: 88271:d453c95def31
> user:Victor Stinner
> date:Fri Jan 03 12:53:47 2014 +0100
> summary:
> add unicode_char() in unicodeobject.c to factorize code
>
> files:
> Objects/unicodeobject.c | 86 ++--
> 1 files changed, 31 insertions(+), 55 deletions(-)
>
>
> diff --git a/Objects/unicodeobject.c b/Objects/unicodeobject.c
> --- a/Objects/unicodeobject.c
> +++ b/Objects/unicodeobject.c
> @@ -2887,17 +2883,7 @@
> return NULL;
> }
>
> -if ((Py_UCS4)ordinal < 256)
> -return get_latin1_char((unsigned char)ordinal);
> -
> -v = PyUnicode_New(1, ordinal);
> -if (v == NULL)
> -return NULL;
> -kind = PyUnicode_KIND(v);
> -data = PyUnicode_DATA(v);
> -PyUnicode_WRITE(kind, data, 0, ordinal);
> -assert(_PyUnicode_CheckConsistency(v, 1));
> -return v;
> +return unicode_char((Py_UCS4)ordinal);
> }
>
> PyObject *
> @@ -11354,17 +11340,7 @@
> kind = PyUnicode_KIND(self);
> data = PyUnicode_DATA(self);
> ch = PyUnicode_READ(kind, data, index);
> -if (ch < 256)
> -return get_latin1_char(ch);
> -
> -res = PyUnicode_New(1, ch);
> -if (res == NULL)
> -return NULL;
> -kind = PyUnicode_KIND(res);
> -data = PyUnicode_DATA(res);
> -PyUnicode_WRITE(kind, data, 0, ch);
> -assert(_PyUnicode_CheckConsistency(res, 1));
> -return res;
> +return unicode_char(ch);
> }
>
> /* Believe it or not, this produces the same value for ASCII strings
The above-quoted parts of this changeset caused several compiler
warnings due to unused variables. On 32-bit Windows:
..\Objects\unicodeobject.c(2881): warning C4101: 'kind' : unreferenced
local variable [P:\ath\to\cpython\PCbuild\pythoncore.vcxproj]
..\Objects\unicodeobject.c(2879): warning C4101: 'v' : unreferenced
local variable [P:\ath\to\cpython\PCbuild\pythoncore.vcxproj]
..\Objects\unicodeobject.c(2880): warning C4101: 'data' : unreferenced
local variable [P:\ath\to\cpython\PCbuild\pythoncore.vcxproj]
..\Objects\unicodeobject.c(11333): warning C4101: 'res' : unreferenced
local variable [P:\ath\to\cpython\PCbuild\pythoncore.vcxproj]
I believe this should fix it, but I'll leave it up to you to confirm
that, Victor :)
diff -r 8a3718f31188 Objects/unicodeobject.c
--- a/Objects/unicodeobject.c Fri Jan 03 15:53:20 2014 +0100
+++ b/Objects/unicodeobject.c Fri Jan 03 10:20:12 2014 -0600
@@ -2876,10 +2876,6 @@
PyObject *
PyUnicode_FromOrdinal(int ordinal)
{
-PyObject *v;
-void *data;
-int kind;
-
if (ordinal < 0 || ordinal > MAX_UNICODE) {
PyErr_SetString(PyExc_ValueError,
"chr() arg not in range(0x11)");
@@ -11330,7 +11326,6 @@
void *data;
enum PyUnicode_Kind kind;
Py_UCS4 ch;
-PyObject *res;
if (!PyUnicode_Check(self) || PyUnicode_READY(self) == -1) {
PyErr_BadArgument();
--
Zach
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Test failures when running as root
On Mon, Jan 13, 2014 at 6:48 PM, Chris Angelico wrote: > And secondly, how can I run the tests manually? I can't find a binary > inside the buildarea tree. Does it get deleted afterward? Yes, that's the 'clean' step of the buildbot build process. I'd suggest making another clone elsewhere (you can clone from the buildarea just to make the clone faster, but I'd leave the buildarea alone otherwise), then building and testing should be as simple as `./configure --with-pydebug && make && ./python -m test.test_posix`. As far as the failure itself, I have no comment. > Apologies if these are dumb questions, hopefully they're a small > distraction from PEP 460 arguments! It's kinda nice to get something non-PEP460 in the inbox this week :) -- Zach ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Changing Clinic's output
On Tue, Jan 14, 2014 at 2:22 PM, Larry Hastings wrote: > I have now received exactly zero feedback about the prototype, which > suggests people aren't using it. Oops, I had half a post written about this two days ago, but never got it posted. I did some experimenting on winreg.c (see http://hg.python.org/sandbox/zware/file/prototype_clinic/PC/winreg.c), and I have to say I really really like having most of the output shunted down to the bottom of the file. In that example I have only the implementation outputting to the block, and everything else (that's necessary) going into the buffer; to me it looks very nice and clean. One of my biggest annoyances with the current output is having the docstring repeated nearly verbatim (with additives) within just a few lines, and this takes care of that and more. To me, those converted functions read about as close to real Python as is ever going to happen in a C file. One thing that I could see being useful (though possibly not easy) is the ability to dump a buffer "late"; for example, near the top of the file: /*[clinic input] destination prototypes new buffer output parser_prototype prototypes dump prototypes later [clinic start generated code]*/ Then process the file, filling the prototypes buffer as we go. At the end of the file, go back and dump the buffer in that output block. I like the flexibility of the prototype, having more control over what goes where is always nice :) -- Zach ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Changing Clinic's output
On Tue, Jan 14, 2014 at 2:54 PM, Larry Hastings wrote: > I will consider you a +1 on the "buffer" approach and NaN on the other > approaches. Oops, I'll give you some real numbers: -1 _pickle.original.c +1 _pickle.using-buffer.c +0 _pickle.using-modified-buffer.c +1 _pickle.using-multiple-buffers.c +0 _pickle.using-sidefile.c > That wouldn't be too hard. But conceptually it would make Clinic much more > complicated. For example, I suggest that "later" is a confusing name, > because the output will actually happen *earlier* in the file. "If it's > hard to explain, it may be a bad idea." ;-) Fair enough :). "later" makes sense to me as "there's nothing in the buffer now, but there will be later; dump it here then". The spark for this idea is in _winapi.c, where OverlappedObject's methoddef is actually before any of the methods are implemented which makes a certain amount of sense as a list of what will be implemented; but as far as I can tell, it isn't possible to replicate this with Clinic right now. Having read the readme in your examples, this could also help with the chicken-and-egg problem you talked about using the various buffers: dump docstrings at the top, followed by prototypes, then methoddef defines near where they're needed (or even perhaps output them directly into the PyMethodDef structure, no defines needed). -- Zach ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] .clinic.c vs .c.clinic
On Sat, Jan 18, 2014 at 12:10 PM, Serhiy Storchaka wrote: > 18.01.14 19:09, Antoine Pitrou написав(ла): > >> On Sat, 18 Jan 2014 18:06:06 +0100 >> Stefan Krah wrote: I'd rather see memoryview.h than memoryview.clinic.c. >>> >>> >>> Or, if this collides with Include/*, one of the following: >>> >>> memoryview_func.h // public functions >>> >>> memoryview_if.h // public interface >> >> >> Objects/memoryview.clinic.h should be fine. > > > All my objections against .clinic.c are applicable to .clinic.h as well. Would it be of any help for the clinic files to live in their own separate directory? Say, instead of Objects/memoryview.clinic.c, Clinic/memoryview.clinic.c? -- Zach ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] .clinic.c vs .c.clinic
On Mon, Jan 20, 2014 at 2:05 AM, Larry Hastings wrote: > Contestant 1: "Add .clinic.h" > > foo.c -> foo.c.clinic.h > foo.h -> foo.h.clinic.h -0 > Contestant 2: "Add .ac.h" > > foo.c -> foo.c.ac.h > foo.h -> foo.h.ac.h -1 > Contestant 3: "Add .clinic" > > foo.c -> foo.c.clinic > foo.h -> foo.h.clinic -0 > Contestant 4: "Put in clinic directory, add .h" > > foo.c -> clinic/foo.c.h > foo.h -> clinic/foo.h.h +1 > Contestant 5: "Put in __clinic__ directory, add .h" > > foo.c -> __clinic__/foo.c.h > foo.h -> __clinic__/foo.h.h +0 -- Zach ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Quick poll: should help() show bound arguments?
On Fri, Jan 24, 2014 at 10:07 PM, Larry Hastings wrote:
>
> (Quick, because apparently nobody reads the long ones!)
>
> In Python 3.3:
>
class C:
> ...def foo(self, a): pass
> ...
c = C()
help(c.foo)
>
> shows you the signature "foo(self, a)". As in, it claims it accepts two
> parameters. The function actually only accepts one parameter, because
> "self" has already been bound. inspect.signature gets this right:
>
import inspect
str(inspect.signature(c.foo))
> '(a)'
>
> but inspect.getfullargspec does not:
>
inspect.getfullargspec(c.foo)
> FullArgSpec(args=['self', 'a'], varargs=None, varkw=None, defaults=None,
> kwonlyargs=[], kwonlydefaults=None, annotations={})
>
>
> help() gets its text from pydoc. pydoc uses inspect.getfullargspec to
> produce the signature.
>
> When I added support for introspection on builtins, I wanted help() to show
> their signature too. But inspect.getfullargspec doesn't support
> introspection on builtins. So I had to use inspect.signature. Which means
> the behavior is inconsistent: help() on a method of an instance of a builtin
> class *doesn't* show "self".
>
>
> FYI, the relevant issues:
>
> help(instance_of_builtin_class.method) does not display self
>
> http://bugs.python.org/issue20379
>
> inspect.getfullargspec should use __siganture__
>
> http://bugs.python.org/issue17481
>
>
> What should it be?
>
> A) pydoc and help() should not show bound parameters in the signature, like
> inspect.signature.
> B) pydoc and help() should show bound parameters in the signature, like
> inspect.getfullargspec.
>
> I'll tally the results if there's interest. I'd assume a "vote for A" = +1
> on A and -1 on B. You can express your vote numerically if you like. I'm
> voting for A.
>
I vote A: it makes sense (though B does too, to an extent), and the
patch to make help() consistent for Python and C implemented methods
is simply removing two lines from pydoc. I'm not sure how convoluted
it might become to make it work the other way.
--
Zach
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] BugFix for "time" native module in Python 2.7
Hi Victor, On Mon, Feb 3, 2014 at 1:41 PM, Виктор Щерба wrote: > Hi, guys! > > I have found a bug in module "time" function "sleep" in Python 2.7 under > Windows XP / Server 2003 and lower. > I fix this bug locally. But how could I send you hg patch or pull request > or, maybe, commit to sandbox? Please open an issue on the bug tracker (http://bugs.python.org/) and attach your patch. > P.S.: Sorry for my English :-) Your English is better than that of most (American) teenagers I know, don't worry :) -- Zach ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The docstring hack for signature information has to go
On Mon, Feb 3, 2014 at 8:43 AM, Larry Hastings wrote:
>
>
> A quick summary of the context: currently in CPython 3.4, a builtin function
> can publish its "signature" as a specially encoded line at the top of its
> docstring. CPython internally detects this line inside
> PyCFunctionObject.__doc__ and skips past it, and there's a new getter at
> PyCFunctionObject.__text_signature__ that returns just this line. As an
> example, the signature for os.stat looks like this:
>
> sig=($module, path, *, dir_fd=None, follow_symlinks=True)
>
> The convention is, if you have this signature, you shouldn't have your
> docstring start with a handwritten signature like 3.3 and before. help() on
> a callable displays the signature automatically if it can, so if you *also*
> had a handwritten signature, help() would show two signatures. That would
> look dumb.
>
> -
>
> So here's the problem. Let's say you want to write an extension that will
> work with Python 3.3 and 3.4, using the stable ABI. If you don't add this
> line, then in 3.4 you won't have introspection information, drat. But if
> you *do* add this line, your docstring will look mildly stupid in 3.3,
> because it'll have this unsightly "sig=(" line at the top. And it *won't*
> have a nice handwritten docstring. (And if you added both a sig= signature
> *and* a handwritten signature, in 3.4 it would display both. That would
> also look dumb.)
What about just choosing a marker value that is somewhat less
unsightly? "signature = (", or "parameters: (", or something (better)
to that effect? It may not be beautiful in 3.3, but we can at least
make it make sense.
--
Zach
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: Close #20656: Fix select.select() on OpenBSD 64-bit
On Mon, Feb 17, 2014 at 6:36 PM, victor.stinner
wrote:
> http://hg.python.org/cpython/rev/79ccf36b0fd0
> changeset: 89239:79ccf36b0fd0
> user:Victor Stinner
> date:Tue Feb 18 01:35:40 2014 +0100
> summary:
> Close #20656: Fix select.select() on OpenBSD 64-bit
>
> files:
> Modules/selectmodule.c | 22 --
> 1 files changed, 12 insertions(+), 10 deletions(-)
This changeset caused a compile warning on 32-bit Windows:
..\Modules\selectmodule.c(238): warning C4244: '=' : conversion from
'time_t' to 'long', possible loss of data
[P:\ath\to\cpython\PCbuild\select.vcxproj]
> diff --git a/Modules/selectmodule.c b/Modules/selectmodule.c
> --- a/Modules/selectmodule.c
> +++ b/Modules/selectmodule.c
> @@ -212,11 +212,18 @@
> return NULL;
> }
> else {
> -#ifdef MS_WINDOWS
> +/* On OpenBSD 5.4, timeval.tv_sec is a long.
> + * Example: long is 64-bit, whereas time_t is 32-bit. */
> time_t sec;
> -if (_PyTime_ObjectToTimeval(tout, &sec, &tv.tv_usec,
> +/* On OS X 64-bit, timeval.tv_usec is an int (and thus still 4
> + bytes as required), but no longer defined by a long. */
> +long usec;
> +if (_PyTime_ObjectToTimeval(tout, &sec, &usec,
> _PyTime_ROUND_UP) == -1)
> return NULL;
> +#ifdef MS_WINDOWS
> +/* On Windows, timeval.tv_sec is a long (32 bit),
> + * whereas time_t can be 64-bit. */
> assert(sizeof(tv.tv_sec) == sizeof(long));
> #if SIZEOF_TIME_T > SIZEOF_LONG
> if (sec > LONG_MAX) {
> @@ -225,16 +232,11 @@
> return NULL;
> }
> #endif
> -tv.tv_sec = (long)sec;
> #else
> -/* 64-bit OS X has struct timeval.tv_usec as an int (and thus still 4
> - bytes as required), but no longer defined by a long. */
> -long tv_usec;
> -if (_PyTime_ObjectToTimeval(tout, &tv.tv_sec, &tv_usec,
> -_PyTime_ROUND_UP) == -1)
> -return NULL;
> -tv.tv_usec = tv_usec;
> +assert(sizeof(tv.tv_sec) >= sizeof(sec));
> #endif
> +tv.tv_sec = sec;
This is the offending line.
I'm not sure how best to fix it, so I'm just pointing it out :)
--
Zach
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Whats New in 3.4 is pretty much done...
On Fri, Mar 14, 2014 at 12:59 AM, Brian Curtin wrote: > On Thu, Mar 13, 2014 at 8:29 PM, Terry Reedy wrote: >> Now that no warnings is a serious goal for 3.4+, I will report them should >> they recur. > > If we're at no warnings, and no warnings is a serious goal, warnings > should be errors. I'm planning to get that done for 3.5, at least on 32bit Windows. I haven't gotten an issue opened for it yet, though. -- Zach ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: Added Doc/tools/ subdirs to .hgignore.
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 >> +++ b/.hgignore >> @@ -24,6 +24,11 @@ >> reflog.txt$ >> tags$ >> Lib/plat-mac/errors.rsrc.df.rsrc >> +Doc/tools/sphinx/ >> +Doc/tools/docutils/ >> +Doc/tools/jinja/ >> +Doc/tools/jinja2/ >> +Doc/tools/pygments/ > > Why are you readding these when they were apparently purposely removed > in eef7899ea7ab? It is rather ugly to build the docs in a 3.3 checkout, then update to default and run 'hg status' without those entries in .hgignore. I can understand not wanting to be bombarded by all of the untracked files, but it's also pretty easy to enable the purge extension and do "hg purge Doc/tools". -- Zach ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: Added Doc/tools/ subdirs to .hgignore.
On Fri, Mar 14, 2014 at 10:55 AM, Benjamin Peterson wrote: > On Fri, Mar 14, 2014, at 08:52 AM, Zachary Ware wrote: >> On Fri, Mar 14, 2014 at 10:10 AM, Benjamin Peterson >> wrote: >> > Why are you readding these when they were apparently purposely removed >> > in eef7899ea7ab? >> >> It is rather ugly to build the docs in a 3.3 checkout, then update to >> default and run 'hg status' without those entries in .hgignore. I can >> understand not wanting to be bombarded by all of the untracked files, >> but it's also pretty easy to enable the purge extension and do "hg >> purge Doc/tools". > > This is why everyone should use the share extension and have separate > working copies for every branch. :) I've been using that setup for a few months now (and cursing myself for not switching sooner), but I've still found myself annoyed by this issue a time or two since the doc build chain change. I personally don't mind whether those entries are in .hgignore or not, but I don't see the harm in them sticking around (at least until 3.3 is out of maintenance; updating from 2.7 to default is a great source of problems even aside from this issue). -- Zach ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython (3.4): simplify check, since now there are only new-style classes
On Tue, Apr 1, 2014 at 1:21 PM, benjamin.peterson wrote: > http://hg.python.org/cpython/rev/abb85902ce79 > changeset: 90090:abb85902ce79 > branch: 3.4 > parent: 90088:4a2dabac976d > user:Benjamin Peterson > date:Tue Apr 01 14:20:56 2014 -0400 > summary: > simplify check, since now there are only new-style classes > > files: > Lib/urllib/request.py | 7 ++- > 1 files changed, 2 insertions(+), 5 deletions(-) > > > diff --git a/Lib/urllib/request.py b/Lib/urllib/request.py > --- a/Lib/urllib/request.py > +++ b/Lib/urllib/request.py > @@ -511,9 +511,6 @@ > If any of the handlers passed as arguments are subclasses of the > default handlers, the default handlers will not be used. > """ > -def isclass(obj): > -return isinstance(obj, type) or hasattr(obj, "__bases__") > - > opener = OpenerDirector() > default_classes = [ProxyHandler, UnknownHandler, HTTPHandler, > HTTPDefaultErrorHandler, HTTPRedirectHandler, > @@ -524,7 +521,7 @@ > skip = set() > for klass in default_classes: > for check in handlers: > -if isclass(check): > +if instance(check, type): Should be isinstance, should it not? -- Zach ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Windows buildbots are red: test_idlelib
On Mon, Apr 7, 2014 at 4:37 AM, Victor Stinner wrote: > Hi, > > Unit tests are failing on Windows because of this issue: > http://bugs.python.org/issue21059 > > It looks like a regression in test_idlelib introduced with this issue: > http://bugs.python.org/issue15968 > > Zachary Ware wrote a fix: > http://bugs.python.org/issue20035 > > Can someone please review Zachary's patch? If not, I suggest to revert > changes of issue #15968 to have working Windows buildbots. Rather than revert the change, I committed what should be a temporary fix last night; Tools/buildbot/test[-amd64].bat now sets TCL_LIBRARY before calling the test script. It seems to be keeping the buildbots happy until #20035 can reach a satisfactory conclusion. -- Zach ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python-3.4.0
On April 13, 2014 10:31:24 AM CDT, Greg Mildenstein wrote: >Hi, > >I'm running windows 8.1 64 bit. I was using 'python-3.3.1.amd64' but >have uninstalled it and installed the above version. However, when I >try running 'PyScripter', I get an error stating, 'ERROR - unable to >open python, it will now exit'. Is there something I'm doing wrong? Hi Greg, All you've done wrong is use the wrong list for your question ;-). Python-dev is intended for discussing the development *of* Python, not development *with* Python. Python-list would have been a better choice of venue, or a PyScripter-specific discussion forum. That said, the problem you're having is because PyScripter has not yet been updated to run with Python 3.4. If you want to stick with PyScripter, you'll have to reinstall Python 3.3 (though I would suggest updating to 3.3.5 instead of 3.3.1). You can install both versions side-by-side without any problems. If you want an IDE that can run Python 3.4, you'll need to use something else until PyScripter updates. Hope this helps, -- Zach (on a phone) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython (3.1): disallow a negative idx parameter
On Mon, Apr 14, 2014 at 10:52 AM, benjamin.peterson
wrote:
> http://hg.python.org/cpython/rev/4bd1fb0f4f44
> changeset: 90256:4bd1fb0f4f44
> branch: 3.1
> parent: 90235:a8facac493ef
> user:Benjamin Peterson
> date:Mon Apr 14 11:45:21 2014 -0400
> summary:
> disallow a negative idx parameter
>
> files:
> Modules/_json.c | 9 +
> 1 files changed, 5 insertions(+), 4 deletions(-)
>
>
> diff --git a/Modules/_json.c b/Modules/_json.c
> --- a/Modules/_json.c
> +++ b/Modules/_json.c
> @@ -902,10 +902,11 @@
> PyObject *res;
> Py_UNICODE *str = PyUnicode_AS_UNICODE(pystr);
> Py_ssize_t length = PyUnicode_GET_SIZE(pystr);
> -if (idx < 0)
> -/* Compatibility with Python version. */
> -idx += length;
> -if (idx < 0 || idx >= length) {
> +if (idx < 0) {
> +PyErr_SetString(PyExc_ValueError, "idx canont be negative");
s/canont/cannot/
Also in the comparable 3.2 commit, but not the 3.3+ merge.
Regards,
--
Zach
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] devguide: Add note about Kushal Das' privs
On Fri, Apr 18, 2014 at 1:54 PM, Brett Cannon wrote: > On Friday, April 18, 2014 2:35:32 PM, Benjamin Peterson > wrote: >> On Fri, Apr 18, 2014, at 11:29, Antoine Pitrou wrote: >> > On Mon, 14 Apr 2014 23:18:42 +0200 (CEST) >> > brett.cannon wrote: >> > > http://hg.python.org/devguide/rev/c14c8a195fec >> > > changeset: 686:c14c8a195fec >> > > user:Brett Cannon >> > > date:Mon Apr 14 17:18:37 2014 -0400 >> > > summary: >> > > Add note about Kushal Das' privs >> > >> > I have no objection to Kushal getting commit rights, but is there a >> > public record of the discussion leading to this decision? I can't find >> > anything on either python-dev or python-committers (perhaps my search >> > skills are failing me). >> >> Probably in person conversion at PyCon sprints > > What Benjamin said; discussions at PyCon amongst several of us. Looking at that page, it doesn't look like I was ever added. Brett, was it you that enabled me? Also, welcome Kushal! -- Zach ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython (3.4): Prevent Sphinx error on whatsnew/changelog
On April 23, 2014 5:24:53 PM CDT, Terry Reedy wrote: >On 4/23/2014 11:05 AM, zach.ware wrote: >> http://hg.python.org/cpython/rev/75419257fec3 >> changeset: 90440:75419257fec3 >> branch: 3.4 >> parent: 90437:5d745d97b7da >> user:Zachary Ware >> date:Wed Apr 23 10:04:20 2014 -0500 >> summary: >>Prevent Sphinx error on whatsnew/changelog >> >> files: >>Misc/NEWS | 2 +- >>1 files changed, 1 insertions(+), 1 deletions(-) >> >> >> diff --git a/Misc/NEWS b/Misc/NEWS >> --- a/Misc/NEWS >> +++ b/Misc/NEWS >> @@ -44,7 +44,7 @@ >> at the same time without losing the Popen.returncode value. >> >> - Issue #21127: Path objects can now be instantiated from str >subclass >> - instances (such as numpy.str_). >> + instances (such as ``numpy.str_``). > >Could you explain this? I thought NEWS was a plain text file without >.rst markup. Doc/whatsnew/changelog.rst includes the full text of Misc/NEWS, which means Sphinx doesn't like markup issues in NEWS. -- Zach (on a phone) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] devguide: Fix broken link to Skip's optimizer paper, update bug link
On Fri, May 2, 2014 at 3:02 PM, zach.ware wrote: > http://hg.python.org/devguide/rev/375b0b0b186b > changeset: 696:375b0b0b186b > user: Zachary Ware > date:Fri May 02 14:44:20 2014 -0500 > summary: > Fix broken link to Skip's optimizer paper, update bug link > > files: > compiler.rst | 4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > > > diff --git a/compiler.rst b/compiler.rst > --- a/compiler.rst > +++ b/compiler.rst > @@ -553,10 +553,10 @@ > .. _SPARK: http://pages.cpsc.ucalgary.ca/~aycock/spark/ > > .. [#skip-peephole] Skip Montanaro's Peephole Optimizer Paper > - > (http://www.python.org/workshops/1998-11/proceedings/papers/montanaro/montanaro.html) > + (http://www.smontanaro.net/python/spam7/optimizer.html) Is this a good link or is there a 'better' one available? This was the first result of a Google search for "skip montanaro peephole optimizer" and seems to be straight from the source, so I went with it :) Regards, -- Zach ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Tix version needed to build 2.7 Windows installer?
On Thu, May 8, 2014 at 2:36 PM, "Martin v. Löwis" wrote: > Am 08.05.14 18:59, schrieb Brian Curtin: >> This is mostly a question for Martin, but perhaps someone else would also >> know. >> >> I'm trying to build the 2.7 installers so I can backport the path >> option from 3.3, but I can't seem to figure out which version of Tix >> is necessary to have a complete build. So far any of them on >> http://svn.python.org/projects/external don't appear to be configured >> to work with the combination of tcl and tk that are used on 2.7, per >> the buildbot external scripts. It's another issue that Tix isn't even >> downloaded by the scripts, but I'll do it manually right now just to >> get this going. >> >> Any tips? > > Ah, 2.7. I was using a checkout of tix-8.4.3.x from Nov 13, 2010, one > where python.mak was pointing to Tcl 8.5.2. It may not have been tagged. > > In 2.7, it wasn't checked out out automatically because Tix requires the > original Tcl/Tk path names, so building it automatically would have failed. I updated the 2.7 buildbot scripts to pull in Tcl/Tk 8.5.15 a couple of weeks ago (see http://bugs.python.org/issue21303), but hadn't gotten anything done with Tix yet. It should just need python.mak updated to point to Tcl/Tk 8.5.15; it's on my list to get fixed as soon as I can. -- Zach ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Tix version needed to build 2.7 Windows installer?
On Thu, May 8, 2014 at 4:20 PM, Zachary Ware wrote: > I updated the 2.7 buildbot scripts to pull in Tcl/Tk 8.5.15 a couple > of weeks ago (see http://bugs.python.org/issue21303), but hadn't > gotten anything done with Tix yet. It should just need python.mak > updated to point to Tcl/Tk 8.5.15; it's on my list to get fixed as > soon as I can. Tix for 2.7 is now http://svn.python.org/projects/external/tix-8.4.3.5. You can build it with this monster of a command, run from tix-8.4.3.5\win: nmake -f python.mak DEBUG=0 MACHINE=IX86 COMPILERFLAGS=-DWINVER=0x0500 TCL_DIR=..\..\tcl-8.5.15.0 TK_DIR=..\..\tk-8.5.15.0 INSTALL_DIR=..\..\tcltk all Use "install" instead of "all" after building to install it to ..\..\tcltk. Set DEBUG and MACHINE as needed; DEBUG does not need to be set if you're building Release, but MACHINE always has to be set so that Tix uses the right build dir for Tk (IX86 for 32-bit, AMD64 for 64-bit). -- Zach ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Moving Python 3.5 on Windows to a new compiler
On Fri, Jun 6, 2014 at 10:41 AM, Steve Dower wrote: > Thoughts/comments/concerns? My only concern is support for elderly versions of Windows, in particular: XP. I seem to recall the last "let's update our MSVC version" discussion dying off because of XP support. Even though MS has abandoned it, I'm not sure whether we can yet. If that's a non-issue, or if we can actually drop XP support, I'm all for it. -- Zach ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Returning Windows file attribute information via os.stat()
On Tue, Jun 10, 2014 at 12:17 PM, Ethan Furman wrote: > On 06/09/2014 09:02 PM, Ben Hoyt wrote: >> To solve this problem, what do people think about adding an >> "st_winattrs" attribute to the object returned by os.stat() on >> Windows? > > > +1 to the idea, whatever the exact implementation. Agreed. -- Zach ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Returning Windows file attribute information via os.stat()
On Tue, Jun 10, 2014 at 2:04 PM, Ben Hoyt wrote: >>> To solve this problem, what do people think about adding an >>> "st_winattrs" attribute to the object returned by os.stat() on >>> Windows? >> >> +1 to the idea, whatever the exact implementation. > > Cool. > > I think we should add a st_winattrs integer attribute (on Windows) and > then also add the FILE_ATTRIBUTES_* constants to stat.py per Paul > Moore. Add to _stat.c rather than stat.py. > What would be the next steps to get this to happen? Open an issue on > bugs.python.org and submit a patch with tests? Yep! -- Zach ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Windows XP, Python 3.5 and PEP 11
On Mon, Jun 16, 2014 at 4:12 PM, Victor Stinner wrote: > Hi, > > I would like to know if Python 3.5 will still support Windows XP or > not. Almost all flavors of Windows XP reached the end-of-life in > April, 2014 except "Windows XP Embedded". There is even an hack to use > Windows upgrades on the desktop flavor using the embedded flavor (by > changing a key in the registry). Extracts of the Wikipedia page: This was recently discussed in the "Moving Python 3.5 on Windows to a new compiler" thread, where Martin declared XP support to be ended [1]. I believe Tim Golden is the only resident Windows dev from whom I haven't seen at least implicit agreement that XP doesn't need further support, so I'd say our support for XP is well and truly dead :) In any case, surely anyone stuck with XP can be happy with Python 3.4. I'm perfectly fine with 3.2 on Win2k! -- Zach [1] https://mail.python.org/pipermail/python-dev/2014-June/134903.html ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Workflow blocked on the 3.6 because of AppVeyor; who owns the AppVeyor project?
On Wed, Sep 5, 2018 at 6:23 AM Antoine Pitrou wrote:
> On Wed, 5 Sep 2018 11:03:48 +0100
> Paul Moore wrote:
> > On Wed, 5 Sep 2018 at 10:55, Victor Stinner wrote:
> > > Who ows the "python" AppVeyor project?
That seems to have fallen to me for the most part.
> > > Can someone please give me the
> > > administrator permission on this project, so I will be able to invalid
> > > the build cache?
> >
> > I don't appear to have admin rights on Appveyor either.
I've attempted to make a change that should give you both more access;
even odds on whether it did anything :). I've never tried to use
their REST API, so I don't know whether it will help with that at all.
> For some reason it seems to be located in a hidden directory
> (".github/appveyor.yml"). Not the most intuitive decision IMHO.
> Travis' own config file ".travis.yml" is still at repository root, which
> makes things more confusing.
The idea there was to avoid proliferation of root-level dotfiles where
possible, but if we would rather keep it at the project root it's a
relatively simple change to make.
For the actual issue at hand, the problem arises from doing builds on
3.6 with both the VS2015 and VS2017 images. Apparently something
built in `/externals` by the VS2015 build gets cached, which then
breaks the VS2017 build; I haven't tracked down how exactly that is
happening. I think the preferred solution is probably to just drop
the VS2017 build on 3.6 on AppVeyor; VSTS runs on VS2017 and dropping
one of the builds from 3.6 will make AppVeyor significantly quicker on
that branch.
--
Zach
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Workflow blocked on the 3.6 because of AppVeyor; who owns the AppVeyor project?
On Wed, Sep 5, 2018 at 9:30 AM Paul Moore wrote: > I presume you're suggesting keeping 2017 is so that we don't have > stray 2015-built artifacts in the cache, which makes sense to me, and > I have a mild preference for keeping the latest compiler, as that's > likely the one that people will find easier to get. But 2015 is > presumably the version the official 3.6 builds are made with, so > there's an argument for keeping that one (although if we do that I > guess we need to find a *different* way of fixing the cached artifact > issue). My fix was actually to keep VS2015 on AppVeyor and leave VS2017 to VSTS, that way we get pre-commit coverage on both compilers. There shouldn't be any caching issues between branches, since PCbuild is sufficiently different between each branch. I wish there was a cache per branch, but there doesn't seem to be. -- Zach ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Stop automerging
It is still up to the core dev to set the message properly, but the HTML comments are invisible on GitHub until you edit the message. That bug is now fixed, though; HTML comments are stripped from the message before creating the commit. -- Zach (Top-posted in HTML from a phone) On Wed, Sep 12, 2018, 01:34 Serhiy Storchaka wrote: > 12.09.18 01:34, Miss Islington (bot) пише: > > > https://github.com/python/cpython/commit/d13e59c1b512069d90efe7ee9b613d3913e79c56 > > commit: d13e59c1b512069d90efe7ee9b613d3913e79c56 > > branch: master > > author: Benjamin Peterson > > committer: Miss Islington (bot) < > 31488909+miss-isling...@users.noreply.github.com> > > date: 2018-09-11T15:29:57-07:00 > > summary: > > > > Make sure the line comes from the same node as the col offset. (GH-9189) > > > > Followup to 90fc8980bbcc5c7dcced3627fe172b0bfd193a3b. > > > > > > This commit message looks awful (and it is duplicated in maintained > branches). Please stop automerging to master by bots. The reason of > automating merging before is that the core dev that performs merging is > responsible for editing the commit message. There were mistakes from > time to time, but usually regular commiters did care of this. > > I often use "git log", and such commit messages spoil the history. > > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/zachary.ware%2Bpydev%40gmail.com > ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
