Re: [Python-Dev] SSL certificates recommendations for downstream python packagers

On 2017-01-31 10:19, Cory Benfield wrote: > >> On 30 Jan 2017, at 21:00, David Cournapeau > > wrote: >> >> >> >> On Mon, Jan 30, 2017 at 8:50 PM, Cory Benfield > > wrote: >> >> >> >> > On 30 Jan 2017, at 13:53, David Cournapeau >

Re: [Python-Dev] Python FTP Injections Allow for Firewall Bypass (oss-security advisory)

On 2017-02-24 11:01, Antoine Pitrou wrote: > On Thu, 23 Feb 2017 23:51:45 -0800 > Benjamin Peterson wrote: >> >> Like all CPython developers, the Python security team are all >> volunteers. That combined with the fact that dealing with security >> issues is one of the least fun programming tasks m

Re: [Python-Dev] python(_hashlib.so) compiled with libssl.so.1.0.1e cannot work with libssl.so.0.9.8e

On 2017-03-15 11:28, Meiling Ge wrote: > Hi, > > I just want to confirm that _hashlib.so in python references something > new in libssl.so.1.0.1e(hmac related?). > > And if we want to work on platforms with libssl.so.0.9.8e, we should > compile python with this lower version, right? OpenSSL 0.9.

Re: [Python-Dev] On "PEP 546 — Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7"

On 2017-06-10 01:56, Benjamin Peterson wrote: > The reason we're having this conversation at all is probably a matter of > timing. If MemoryBIO was in Python 3 when PEP 466 was accepted, it > surely would have come along for the ride to 2.7. I believe PEP 466 is > generally considered to have produ

Re: [Python-Dev] Impact of Namedtuple on startup time

On 2017-07-17 14:43, Antoine Pitrou wrote: > So my take is: > > 1) Usage of "_source" in open source code (as per the search above) > seems non-existent. > > 2) If the primary intent of "_source" is to show-case how to write a > tuple subclass, well, why not write a recipe or tutorial somewhere?

Re: [Python-Dev] python issue27584 AF_VSOCK support

On 2017-08-17 14:21, Cathy Avery wrote: > Hi, > > I have a python pull request https://github.com/python/cpython/pull/2489 > that introduces AF_VSOCK to the python C socket module. Unfortunately > things have gone quiet for several weeks. Since I am new to this process > I am unclear on what to e

Re: [Python-Dev] Compiling without multithreading support -- still useful?

On 2017-09-05 09:42, Victor Stinner wrote: > I proposed to drop the --without-threads option multiple times. I > worked on tiny and cheap embedded devices and we used Python *with* > threads for concurrency. Many Python features require threads, like > asyncio and multiprocessing. Also subprocess.c

[Python-Dev] Re: compiled python3.10 is unable to find _ssl

On 19/10/2021 11.57, Robin Becker wrote: On 18/10/2021 18:50, Senthil Kumaran wrote: Your configure script did pick up openssl as the support version was not found. What is your operating system? Make sure you have supported version of ssl. Python requires openssl 1.1.1 or higher. ... I t

[Python-Dev] Re: compiled python3.10 is unable to find _ssl

On 19/10/2021 17.26, Robin Becker wrote: On 19/10/2021 11:21, Christian Heimes wrote: On 19/10/2021 11.57, Robin Becker wrote: .. For PEP 644 I added new instructions how to build Python 3.10 with custom OpenSSL builds. The instructions should work on all major Linux distributions

[Python-Dev] Re: compiled python3.10 is unable to find _ssl

On 20/10/2021 09.43, Robin Becker wrote: On 19/10/2021 16:45, Christian Heimes wrote: We use the standard AX_CHECK_OPENSSL() m4 macro from autoconf-archive to detect OpenSSL. The macro uses pkg-config to detect OpenSSL. It doesn't check for specific version, though. We don't want

[Python-Dev] Re: Clarification regarding Stable ABI and _Py_*

On 07/12/2021 19.28, Guido van Rossum wrote: I assume it would be insensitive to ask whether we could just get rid of the stable ABI altogether and focus on the limited API? Just tell everyone they have to rebuild binary wheels for every Python feature release. Presumably the deprecation of the

[Python-Dev] Re: Explicit markers for special C-API situations (re: Clarification regarding Stable ABI and _Py_*)

On 09/12/2021 19.26, Petr Viktorin wrote: I'll not get back to CPython until Tuesday, but I'll add a quick note for now. It's a bit blunt for lack of time; please don't be offended. If the code is the authoritative source of truth, we need a proper parser to extract the information. But we can't

[Python-Dev] Re: Explicit markers for special C-API situations

On 10/12/2021 03.08, Jim J. Jewett wrote: Christian Heimes wrote: On 09/12/2021 19.26, Petr Viktorin wrote: If the code is the authoritative source of truth, we need a proper parser to extract the information. ... unfortunately I don't trust it enough to let it define the API. Bugs i

[Python-Dev] Re: Python release announcement format

On 14/12/2021 11.56, Yann Droneaud wrote: Hi, I'm not familiar with the Python release process, but looking at the latest release https://www.python.org/downloads/release/python-3101/ we can see MD5 is still used ... which doesn't sound right in 2021 ... especially since we proved it's possib

[Python-Dev] Re: "immortal" objects and how they would help per-interpreter GIL

On 14/12/2021 19.19, Eric Snow wrote: A while back I concluded that neither approach would work for us. The approach I had taken would have significant cache performance penalties in a per-interpreter GIL world. The approach that modifies Py_INCREF() has a significant performance penalty due to

[Python-Dev] [PSA] OpenSSL 3.0 support is preliminary and experimental

Hi, I would like to remind everybody that Python's support for OpenSSL 3.0 is preliminary [1]. Python compiles with OpenSSL 3.0.0 and simple code kinda works. However there are known performance regressions, missing features (e.g. usedforsecurity flag), and potential bugs cause by API incompa

[Python-Dev] Re: [PSA] OpenSSL 3.0 support is preliminary and experimental

On 11/01/2022 12.02, Antoine Pitrou wrote: Hi Christian, On Sun, 9 Jan 2022 19:39:06 +0100 Christian Heimes wrote: Hi, I would like to remind everybody that Python's support for OpenSSL 3.0 is preliminary [1]. Python compiles with OpenSSL 3.0.0 and simple code kinda works. However ther

[Python-Dev] Re: [PSA] OpenSSL 3.0 support is preliminary and experimental

On 10/01/2022 17.01, Miro Hrončok wrote: On 09. 01. 22 19:39, Christian Heimes wrote: Hi, I would like to remind everybody that Python's support for OpenSSL 3.0 is preliminary [1]. Python compiles with OpenSSL 3.0.0 and simple code kinda works. However there are known performance regres

[Python-Dev] Re: Dropping AC_C_CHAR_UNSIGNED from configure.ac?

On 24/01/2022 14.34, Miro Hrončok wrote: Hello Pythonistas. In (development branch of) Fedora, we have juts upgraded to GCC 12. It seems that the presence of AC_C_CHAR_UNSIGNED in Python's autotools files (configure.ac?) is causing the __CHAR_UNSIGNED__ symbol to be defined in pyconfig.h and

[Python-Dev] Re: Please update Cython *before* introcuding C API incompatible changes in Python

On 01/02/2022 16.08, Victor Stinner wrote: -- I would prefer to introduce C API incompatible changes differently: first fix Cython, and *then* introduce the change. - (1) Propose a Cython PR and get it merged - (2) Wait until a new Cython version is released - (3) If possible, wait until numpy

[Python-Dev] Re: Please update Cython *before* introcuding C API incompatible changes in Python

On 02/02/2022 09.19, dw-...@d-woods.co.uk wrote: Guido van Rossum wrote: My question for you is if you're willing to write up a list of things in CPython that you depend on. Or is this just something you're not willing to commit to? It would be nice to know which it is, just so the CPython team

[Python-Dev] Re: It's now time to deprecate the stdlib urllib module

On 06/02/2022 15.08, Victor Stinner wrote: Hi, I propose to deprecate the urllib module in Python 3.11. It would emit a DeprecationWarning which warn users, so users should consider better alternatives like urllib3 or httpx: well known modules, better maintained, more secure, support HTTP/2 (htt

[Python-Dev] Re: Defining tiered platform support

Hi Brett, thanks for starting the discussion! Much appreciated. On 04/03/2022 00.30, Brett Cannon wrote: Tier 1 is the stuff we run CI against: latest Windows, latest macOS, Linux w/ the latest glibc (I don't know of a better way to define Linux support as I don't know if a per-distro list is

[Python-Dev] Re: Defining tiered platform support

On 04/03/2022 21.41, Brett Cannon wrote: Therefore I propose that we target the oldest manylinux standard accepted by PyPI, for which the operating system has not reached its EOL. At the moment this is manylinux2014, aka CentOS 2024 with EOL June 2024. We could also state that we

[Python-Dev] Re: Defining tiered platform support

On 07/03/2022 18.02, Petr Viktorin wrote: Why the devguide? I view the list of platforms as important for public consumption as for the core dev team to know what to (not) accept PRs for. So, let's put it in the main docs? Yes, I guess the devguide is a weird place to check for this kind of i

[Python-Dev] Re: Supported make implementations

On 12/03/2022 06.27, Lincoln Auster wrote: Hi, When attempting to build and run doctests for cpython on FreeBSD, I got a vague error from the default BSD make. gmake, of course, ran fine. Is GNU make the only supported make implementation? If so, did I miss that in the devguide, or should that b

[Python-Dev] Re: Migration plan for the distutils removal in Python 3.12

On 10/05/2022 09.53, Victor Stinner wrote: Hi, Two years ago, PEP 632 "Deprecate distutils module" was accepted: the distutils package was deprecated in Python 3.10 and scheduled for removal in Python 3.12. Questions. * Is the Python ecosystem ready for the distutils removal? How many projects

[Python-Dev] Re: Migration plan for the distutils removal in Python 3.12

On 10/05/2022 09.53, Victor Stinner wrote: Hi, Two years ago, PEP 632 "Deprecate distutils module" was accepted: the distutils package was deprecated in Python 3.10 and scheduled for removal in Python 3.12. Questions. * Is the Python ecosystem ready for the distutils removal? How many projects

[Python-Dev] Re: Migration plan for the distutils removal in Python 3.12

On 10/05/2022 13.18, Victor Stinner wrote: On Tue, May 10, 2022 at 11:28 AM Christian Heimes wrote: Right now, Python still uses distutils internally for multiple use cases. I propose to start with renaming the distutils package to _distutils in the stdlib: * https://github.com/python/cpython

[Python-Dev] Re: [Python-Help] Unable to bootstrap Python 3 install

On 16/06/2022 16.29, Xavier de Gaye wrote: Victor Stinner wrote: > https://github.com/python/cpython/issues/66913 doesn't explain how to reproduce the issue, it only gives some info about what doesn't work. > I don't know how to reproduce the

[Python-Dev] Re: How To Get Started

On 28/07/2022 18.34, kiddkod...@gmail.com wrote: New coding bootcamp graduate here looking actively for my first programming job. In the meantime, I want to start contributing to open source which brought me here. But after consulting the Python's Developer Guide, I'm still faced with some con

[Python-Dev] Re: urllib request HTTPS memory leak?

On 16/09/2019 23.37, V-ron P wrote: > Hello Python Dev, > > One of my HTTPS servers leaked over 8 GB of memory over the past week. > After troubleshooting the issue, I managed to narrow it down to the > minimal test case below: > > https://gist.github.com/hydrogen-mvm/d588521c2138e0f98aa94b18e7de

[Python-Dev] Re: Restricted Entry Point from PEP-551/578

On 21/11/2019 18.27, Jason Killen wrote: > I sent in a couple of PRs, accepted and merged (Thanks!), lately that > switch to using io.open_code when appropriate.  In the process of making > those PRs I spent a bit of time reading the two related PEPs.  In > PEP-551 there's a suggestion that people

[Python-Dev] Re: Restricted Entry Point from PEP-551/578

On 21/11/2019 21.19, Jason Killen wrote: > I knew the audit hooks were new but didn't realize they were quite that > new.  I didn't mean to come across as pejorative asking if people cared > about this.  The fact that I had trouble finding more information made > me think this good stuff had been l

[Python-Dev] Re: Deprecating the "u" string literal prefix

On 03/12/2019 19.09, Barry Warsaw wrote: > On Dec 3, 2019, at 09:16, Serhiy Storchaka > wrote: >> >> The 'u" string literal prefix was removed in 3.0 and reintroduced >> in 3.3 to help writing the code compatible with Python 2 and 3 >> [1]. After the dead of Python 2.7 we will remove some deprecat

[Python-Dev] Re: Deprecating the "u" string literal prefix

On 03/12/2019 21.04, Ethan Furman wrote: > On 12/03/2019 09:31 AM, Guido van Rossum wrote: > >> I think it’s too soon to worry about this. I don’t see a reason to >> harass people who maintain code based that were just recently migrated. > > I'm happy to go with this, since my libraries still do

[Python-Dev] Re: Documenting sorted/min/max prerequisites

On 14/12/2019 15.20, Serhiy Storchaka wrote: > 14.12.19 15:29, Steven D'Aprano пише: >> I might be misinterpreting the evidence, but sorting works on objects >> that define `__gt__` without `__lt__`. >> >> py> class A: >> ... def __init__(self, x): self.x = x >> ... def __gt__(self, other):

[Python-Dev] Re: sqlite3 module and thread-safe SQLite library

On 18/12/2019 00.56, Gregory P. Smith wrote: > > On Tue, Dec 17, 2019 at 12:30 PM Kacvinsky, Tom > mailto:tom.kacvin...@vector.com>> wrote: > > We ran into an issue where having the SQLite library built with > -DSQLITE_THREADSAFE=0, > but then the sqlite3 module (really, the _sqlite3.

[Python-Dev] Re: test_ssl.py hangs with SSL 1.1 built with no threads

On 27/04/2020 19.27, mig28sua...@hotmail.com wrote: > Hello! > > This is my first time posting to the group. > > I've been running builds of Python 3.7.x on CentOS Linux release 7.7 > (64bit/Intel Core 2 Duo) > and I ran into hangs with test_ssl.py when using latest SSL 1.1.1d sources. > > I

[Python-Dev] [OT] I'm unsubscribing from this tire fire (formerly known as python-dev)

Y'all, trigger warning: strong opinion The Urban Dictionary defines the term "tire fire": A horrifying mess, either literally or figuratively foul-smelling, that seems to last forever. The term describes my current view of python-dev perfectly. It has always been a problematic and mentally

[Python-Dev] Re: [python-committers] Resignation from Stefan Krah

On 09/10/2020 04.04, Ivan Pozdeev via Python-Dev wrote: > I don't see the point of requiring to "write an apology", especially > *before a 12-month ban*. If they understand that their behavior is > wrong, there's no need for a ban, at least not such a long one; if they > don't, they clearly aren't

[Python-Dev] Re: [python-committers] Resignation from Stefan Krah

On 09/10/2020 15.48, Antoine Pitrou wrote: > On Fri, 9 Oct 2020 05:04:55 +0300 > Ivan Pozdeev via Python-Dev wrote: >> I don't see the point of requiring to "write an apology", especially *before >> a 12-month ban*. If they understand that their behavior is >> wrong, there's no need for a ban, a

Re: [Python-Dev] multiprocessing not compatible with functional.partial

Neal Becker schrieb: > If the argument to pool.map (f, args) > is > f = functional.partial (my_func, some_keyword_arg=whatever) > > I get: > > Traceback (most recent call last): > File "/usr/lib/python2.5/site-packages/multiprocessing-2.6.1.1-py2.5-linux- > self.run() > File "/usr/lib/pyt

Re: [Python-Dev] Duck-typing self

Steven Bethard wrote: >> Is it a design decision that duck-typing self does not work or is there a >> technical reason? From a practical standpoint it seems that being able to >> duck-type self has merit, for example in unit testing complex classes. > > Works for me in 3.0: It works in 3.0 becaus

Re: [Python-Dev] Python jail: whitelist vs blacklist

Victor Stinner wrote: > This approach was implemented in PyPy using two interpreters. > > In CPython, we may use proxies on anything to check all operations. > jail -- validations --> real world > jail <-- proxy objects -- real world > > tav's jail might be converted to the whitelist appro

Re: [Python-Dev] How do I get commit access?

Chris Withers wrote: > But still, no answer to my original question... Hey Chris, long time no see! Your question is covered by the developer FAQ http://python.org/dev/faq/#how-can-i-become-a-developer. You can get write privileges by providing a constant flow of good patches. Eventually you get

Re: [Python-Dev] 3.1 performance

Antoine Pitrou wrote: > Hi, > > Victor Stinner haypocalc.com> writes: >> Summary (minimum total) on 32 bits CPU: >> * Python 2.6.1: 8762 ms >> * Python 3.0.1: 8977 ms >> * Python 3.1a1: 9228 ms (slower than 3.0) > > Have you compiled with or without "--with-computed-gotos"? Why is the featur

[Python-Dev] Ext4 data loss

Multiple blogs and news sites are swamped with a discussion about ext4 and KDE 4.0. Theodore Ts'o - the developer of ext4 - explains the issue at https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/317781/comments/54. Python's file type doesn't use fsync() and be the victim of the very same

Re: [Python-Dev] Ext4 data loss

Guido van Rossum wrote: > If I understand the post properly, it's up to the app to call fsync(), > and it's only necessary when you're doing one of the rename dances, or > updating a file in place. Basically, as he explains, fsync() is a very > heavyweight operation; I'm against calling it by defau

Re: [Python-Dev] Ext4 data loss

Antoine Pitrou wrote: > Christian Heimes cheimes.de> writes: >> I agree with you, fsync() shouldn't be called by default. I didn't plan >> on adding fsync() calls all over our code. However I like to suggest a >> file.sync() method and a synced flag for files

Re: [Python-Dev] Ext4 data loss

Guido van Rossum wrote: > Let's not think too Unix-specific. If we add such an API it should do > something on Windows too -- the app shouldn't have to test for the > presence of the API. (And thus the API probably shouldn't be called > fsync.) In my initial proposal one and a half hour earlier I

Re: [Python-Dev] Ext4 data loss

Antoine Pitrou schrieb: > After Hrvoje's message, let me rephrase my suggestion. Let's instead allow: >open(..., sync_on="close") >open(..., sync_on="flush") > > with a default of None meaning no implicit syncs. And sync_on="flush" implies sync_on="close"? Your suggestion sounds like the

Re: [Python-Dev] Fwd: installation with ubuntu 8.04

Steve Holden wrote: > Look in the build instructions for "alt-install", and make sure that you > *know* when you install the new Python that it isn't touching the system > Python at all. Always run make -n install and check what the script will > do before running it until you know what you are doi

[Python-Dev] Multiprocessing on Solaris

Hello fellow co-developers! Today I was in contact with a Python user who tried to compile pyprocessing - the ancestor of multiprocessing - on Solaris. It failed to run because Solaris is missing two features (HAVE_FD_TRANSFER and HAVE_SEM_TIMEDWAIT). Does anybody have a Solaris box at his disposa

Re: [Python-Dev] Multiprocessing on Solaris

Martin v. Löwis schrieb: >> Today I was in contact with a Python user who tried to compile >> pyprocessing - the ancestor of multiprocessing - on Solaris. It failed >> to run because Solaris is missing two features (HAVE_FD_TRANSFER and >> HAVE_SEM_TIMEDWAIT). Does anybody have a Solaris box at his

Re: [Python-Dev] Multiprocessing on Solaris

Martin v. Löwis schrieb: >> According to the user's experience multiprocessing should not compile >> and run correctly unless this patch is applied. > > Can this please be more qualified? I can confirm Scott's observation: > for the trunk, it compiles just fine, using SunPro CC on Solaris 10, > on

Re: [Python-Dev] Multiprocessing on Solaris

Martin v. Löwis wrote: > I think multiprocessing is misguided in hard-coding these settings > into setup.py. As we can see, the necessary features are available > on some versions of Solaris, but not on others. It would be better > if autoconf tests were written, and the entire configuration remove

Re: [Python-Dev] Multiprocessing on Solaris

Jesse Noller wrote: > Christian - I would appreciate it if we could coordinate/track this on > the tracker too - I had no idea you were doing this in the back port, > and I don't think we want the two code bases to diverge that much. You could not have known about the idea because I started the ex

Re: [Python-Dev] Evaluated cmake as an autoconf replacement

Jeffrey Yasskin wrote: > 1. It can autogenerate the Visual Studio project files instead of > needing them to be maintained separately I'm familiar with the Unix and the Windows build system. More than a year ago I went to a great deal of work to migrate the Windows builds from VS 7.1 to VS 9.0.

Re: [Python-Dev] Evaluated cmake as an autoconf replacement

Hallo Alexander! Alexander Neundorf wrote: > This of course depends on the definition of "as good as" ;-) > Well, I have met Windows-only developers which use CMake because it is > able to generate project files for different versions of Visual > Studio, and praise it for that. So far I haven't h

Re: [Python-Dev] Evaluated cmake as an autoconf replacement

David Cournapeau wrote: > On Tue, Mar 31, 2009 at 3:16 AM, Alexander Neundorf > wrote: >> Can you please explain ? What is "those" ? > > Everything in Lib. On windows, I believe this is done through project > files, but on linux at least, and I guess on most other OS, those are > handled by distu

Re: [Python-Dev] PyDict_SetItem hook

John Ehresman wrote: > * To what extent should non-debugger code use the hook? At one end of > the spectrum, the hook could be made readily available for non-debug use > and at the other end, it could be documented as being debug only, > disabled in python -O, & not exposed in the stdlib to python

Re: [Python-Dev] Mercurial?

Martin v. Löwis wrote: > I would personally remove all non-mercurial stuff out of PEP 374, > and retitle it, but that would be your choice. I suggest we keep the old PEP and start a new one about Hg exclusively. The original PEP 374 has cost Brett a lot of time. It would be a shame to throw it awa

Re: [Python-Dev] Rethinking intern() and its data structure

John Arbash Meinel wrote: > When I looked at the actual references from interned, I saw mostly > variable names. Considering that every variable goes through the python > intern dict. And when you look at the intern function, it doesn't use > setdefault logic, it actually does a get() followed by a

Re: [Python-Dev] Avoiding file descriptors leakage in subprocess.Popen()

Facundo Batista wrote: > I just don't like a huge try/finally... but as FDs are just ints, do > you think is there a better way to handle it? How about a nice 'n shiny context wrapper for the pipe: import os class Pipe(object): def __enter__(self): self.read, self.write = os.pipe()

Re: [Python-Dev] Avoiding file descriptors leakage in subprocess.Popen()

Facundo Batista wrote: > I just don't like a huge try/finally... but as FDs are just ints, do > you think is there a better way to handle it? How about a nice 'n shiny context wrapper for the pipe: import os class Pipe(object): def __enter__(self): self.read, self.write = os.pipe()

Re: [Python-Dev] Functions that steal references (Re: [pygame] [patch] minor memory leaks...)

Benjamin Peterson schrieb: > 2009/6/16 Greg Ewing : >> Lenard Lindstrom wrote: >> >>> I assumed that since PyModule_AddObject is documented as stealing a >>> reference, it always stole a reference. But in reality it only does so >>> conditionally, when it succeeds. >> As an aside, is this a general

Re: [Python-Dev] Popen asynchronous input for Windows

Eric Pruitt schrieb: > Hello, > > I am looking for alternatives to Josiah Carlson's asynchronous I/O patch for > subprocess.Popen. While his patch seems to work well, it relies on pywin32 > which is not part of the standard Python library. If I cannot find an > alternative, I will be using cTypes

Re: [Python-Dev] Adding syntax for units of measure

Tobias C. Rittweiler schrieb: > Hi! > > Has anyone added special syntax to allow writing numeric literals with > physical units? So you can write 12m + 34cm, and would get 12.34m. > > My question is how would you modify the BNF the most sensible way to > allow for this? The above example is simpl

Re: [Python-Dev] [RELEASED] Python 3.1 final

Benjamin Peterson schrieb: > On behalf of the Python development team, I'm thrilled to announce the first > production release of Python 3.1. Gratulations! You did a fantastic job! :) Christian PS: I hope that I'm able to spare more of my work time on the development of Python 3.2 ... __

Re: [Python-Dev] Define metatype and a type that uses it

Erik Groeneveld wrote: > L.S. > > I am working on an extension that allows one to open Java .jar files > and use the objects defined in it (via CNI or JNI) in Python. It > works like a charm, but I am stuck with the definition of a metatype > for the wrappers. I have to do this in Python now, wi

Re: [Python-Dev] Support for Python/Windows

Steve Holden wrote: > Devs: > > I've been in correspondence with Microsoft about the provision of > software, and it transpires that if you want to support Windows better > Microsoft will be quite liberal about licensing: they will *give* you a > Microsoft Developer Network license. > > If you ar

Re: [Python-Dev] Support for Python/Windows

Curt Hagenlocher wrote: > Considering that the compilers are all freely downloadable as part of > the Windows SDK, it would be weird if the subscription were *more* > restrictive than what you can get without it. > > Disclaimer: I work for Microsoft, but eh, I'm just guessing. Some features like

Re: [Python-Dev] Replacing PyWin32's PeekNamedPipe, ReadFile, and WriteFile

Lisandro Dalcin wrote: > Eric seems to be working on a GSoC for PFS related to improving > subprocess. Even in such case this list is not the right place to make > these posts?? Eric didn't say that he is working on a GSoC project for the PSF. Anyway the Python general mailing list might still be

Re: [Python-Dev] Replacing PyWin32's PeekNamedPipe, ReadFile, and WriteFile

Michael Foord wrote: > A big advantage of using ctypes is that it works cross-implementation - > on IronPython and PyPy already and on Jython soon. I'd like to see more > standard library modules use it. Distributions that choose not to > include it are crippling their Python distribution. Interes

Re: [Python-Dev] Replacing PyWin32's PeekNamedPipe, ReadFile, and WriteFile

Nick Coghlan wrote: > I see ctypes as largely useful when you want to call a native DLL but > don't have any existing infrastructure for accessing native code from > your project. A few lines of ctypes code is then a much better solution > than adding a C or C++ compilation dependency just to acces

Re: [Python-Dev] Update to Python Documentation Website Request

david.l...@preisshare.net wrote: >> That's a document describing how to use âdistutilsâ, which is what >> every >> recipient of Python will already have installed. >> >>> Can I ask that you also provide a link for windows users >>> to my project: >>> >>> http://sourceforge.net/projects/python

Re: [Python-Dev] mingw32 and gc-header weirdness

Christian Tismer wrote: > We should keep Martin's hint in mind, that Python 4 could place > the gc header at the end of structures, instead. Wow, 3.1 just came out and we already have the first PEP for Python 4k? :) Christian ___ Python-Dev mailing list

Re: [Python-Dev] Microsoft MSDN

Steve Holden wrote: I sent fourteen requests for licenses in to Microsoft. I've asked them to let me know which they grant (since they may choose to limit the number) and will inform you all personally when I hear their decision. I've received my MSDN subscription today. Everybody watch out for

Re: [Python-Dev] Adding a C Module to python source distribution

Shashank Singh wrote: > Do I need to register this module some place else too (setup.py?) ? > > Any hints and pointers will be appreciated :) You have to add the module and its initializer to PC/config.c, too. Christian ___ Python-Dev mailing list Pyth

Re: [Python-Dev] eggs now mandatory for pypi?

Fredrik Lundh wrote: > Oh, it was just yet another Zope developer behaving like an ass. Why > am I not surprised? > > > > On Mon, Oct 5, 2009 at 10:43 AM, Fredrik Lundh wrote: >> it's reviews like this that makes me wonder if releasing open source is >> a good idea: >> >> no egg - worst seen

[Python-Dev] PEP 370 and IronPython

Dear Pythonistas! Michael Foord has written a blog posting [1] regarding IronPython, site packages and my PEP 370. I'm referring to the section that talks about an issue with PEP 370. --- If you install CPython 2.6 on Windows it creates a folder in the location: %APPDATA%\Python\Python26\site-pac

Re: [Python-Dev] PEP 370 and IronPython

Nick Coghlan wrote: > Christian Heimes wrote: >> The solution requires a new attribute in the sys module that contains >> the name of the implementation. As an alternative we could use the first >> field of sys.subversion but I prefer an explicit attribute. I'm >> p

Re: [Python-Dev] PEP 370 and IronPython

Tarek Ziadé wrote: > I have a suggestion though, that completes Nick's answer. > > distutils/command/install.py already contains install schemes and > imports USER_SITE and USER_BASE to builds user-specific install > schemes. I think it wouldn't hurt for clarity to reunite all these > schemes in a

Re: [Python-Dev] PEP 370 and IronPython

Antoine Pitrou wrote: > `usersitesuffix` should probably be a separate sys attribute, since it doesn't > depend on the VM only, but also on the platform and version. I don't really care and I'm happy to follow the herd in this matter. :) Christian ___

Re: [Python-Dev] PEP 370 and IronPython

Michael Foord wrote: > I really like this scheme. The important thing for IronPython is that we > can get it into Python 2.6 (along with other fixes to make distutils > compatible with IronPython - like not attempting to bytecode-compile > when sys.dont_write_bytecode is True). I don't think my

[Python-Dev] PEP about sys.implementation and implementation specific user site directory

Fellow Python developers! In the light of our recent discussion about implementation specific information and user site directory I like to start a new PEP. Much to my regret I wasn't able to contribute to Python core development over the past months. I hope I can find some free time over the next

Re: [Python-Dev] PEP about sys.implementation and implementation specific user site directory

Benjamin Peterson wrote: >> sys.implementation is a PyStructSequence that contains various >> information about the current implementation. Some fields are required >> to be present on every implementation. Implementations may choose to add >> additional fields as they see fit. Some fields like com

Re: [Python-Dev] PEP about sys.implementation and implementation specific user site directory

Martin v. Löwis wrote: >> Given that this is all about establishing some common ground between >> implementations I would propose not using a CPython specific term >> here such as PyStructSequence :) The Python docs seem to use structseq >> for sys.float_info. > > Also, why does it have to be a s

Re: [Python-Dev] PEP about sys.implementation and implementation specific user site directory

Martin v. Löwis wrote: >> sys.implementation is a PyStructSequence that contains various >> information about the current implementation. Some fields are required >> to be present on every implementation. > > I think it is important to confirm in advance that all the > implementations listed below

Re: [Python-Dev] PEP about sys.implementation and implementation specific user site directory

Dino Viehland wrote: > Given that this is all about establishing some common ground between > implementations I would propose not using a CPython specific term > here such as PyStructSequence :) The Python docs seem to use structseq > for sys.float_info. You got me! :) >> compiler (required): >>

Re: [Python-Dev] PEP about sys.implementation and implementation specific user site directory

Benjamin Peterson wrote: > I think we should make a semi-private (public to the stdlib) module > like _sys or _implementation part of the Python VM API. Then, instead > of stuffing everything into sys, we can provide this information in > modules where it belongs. That's an interesting counter pr

Re: [Python-Dev] Clean up Python/thread_*.h ?

Antoine Pitrou wrote: > * The unused file: thread_wince.h > > Windows CE has actually been using thread_nt.h since January 2009 (see > http://bugs.python.org/issue4893 ). thread_wince.h is still there, but it's > unused and grep brings no instance of it being mentioned anywhere in the > source >

Re: [Python-Dev] MSDN subscribers: Using Visual Studio?

Daniel Stutzbach wrote: > It does. If I recall correctly, in addition to Visual Studio Express, I > also needed the Windows SDK (which is also free as in beer). The VS 2008 Express Edition is sufficient to build X86 binaries on Windows. The express edition doesn't support X64_86. though. Christi

Re: [Python-Dev] Reworking the GIL

Antoine Pitrou wrote: > Based on this whole discussion, I think I am going to merge the new GIL work > into the py3k branch, with priority requests disabled. > > If you think this is premature or uncalled for, or if you just want to review > the changes before making a judgement, please voice up :

Re: [Python-Dev] Reworking the GIL

Antoine Pitrou wrote: > Christian Heimes cheimes.de> writes: >> +1 from me. I trust you like Brett does. >> >> How much work would it cost to make your patch optional at compile time? > > Quite a bit, because it changes the logic for processing asynchronous

Re: [Python-Dev] buildtime vs runtime in Distutils

Tarek Ziadé wrote: > Hello, > > http://bugs.python.org/issue4359 reminds me that Distutils reads build > files like Makefile or pyconfig.h to get some environment > variables through the sysconfig module at *runtime*. > > This cannot work on all platforms, when our Makefile is not shipped > with

Re: [Python-Dev] buildtime vs runtime in Distutils

Tarek Ziadé wrote: > Now for the format problem, I agree that it seems more robust to > pre-process the variables > and inject them in the stdlib when ./configure is run. > > I am not sure what is the best strategy here, but I would rather not > add yet another > configuration file (wether its an

Re: [Python-Dev] wpython is back

Cesare Di Mauro wrote: > > You'll find some at page 28 > here > .. > > Mart made more interesting > oneswith > Unladen benchmarks. The PDF

Re: [Python-Dev] Fwd: Download Page - AMD64

Michael Foord wrote: > I presume the email below is about the Windows binary. Does the AMD64 > release work on intel 64bit and can we make the wording clearer on the > download page? > > The current description is " Windows AMD64 binary". The installer works on all AMD64 compatible Intel CPUs.

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