Re: [Python-Dev] Moving Python 3.5 on Windows to a new compiler

Am 06.06.14 22:13, schrieb Paul Moore: > From http://www.visualstudio.com/en-us/downloads/visual-studio-14-ctp-vs > > """ > Currently, Visual Studio "14" CTPs have known compatibility issues > with previous releases of Visual Studio and should not be installed > side-by-side on the same computer.

Re: [Python-Dev] Moving Python 3.5 on Windows to a new compiler

Am 07.06.14 01:01, schrieb Steve Dower: > We keep the VS 2010 files around and make sure they keep working. > This is the biggest risk of the whole plan, but I believe that > there's enough of a gap between when VS 14 is planned to release > (which I know, but can't share) and when Python 3.5 is pl

Re: [Python-Dev] Moving Python 3.5 on Windows to a new compiler

Am 07.06.14 17:38, schrieb Steve Dower: > One more possible concern that I just thought of is the availability of > the build tools on Windows Vista and Windows 7 RTM (that is, without > SP1). I'd have to check, but I don't believe anything after VS 2012 is > supported on Vista and it's entirely po

Re: [Python-Dev] Python 3.5 on VC14 - update

Am 10.06.14 18:30, schrieb Steve Dower: > I ran a quick test with profile-guided optimization (PGO, pronounced > "pogo"), which has supposedly been improved since VC9, and saw a very > unscientific 20% speed improvement on pybench.py and 10% size > reduction in python35.dll. I'm not sure what we us

Re: [Python-Dev] Issue 21671: CVE-2014-0224 OpenSSL upgrade to 1.0.1h on Windows required

Am 17.06.14 18:41, schrieb Yates, Andy (CS Houston, TX): > Python Dev, > > Andy here. I have a Windows product based on Python and I’m getting > hammered to release a version that includes the fix in OpenSSL 1.0.1h. > My product is built on a Windows system using Python installed from the > stand

Re: [Python-Dev] Issue 21671: CVE-2014-0224 OpenSSL upgrade to 1.0.1h on Windows required

Am 17.06.14 20:27, schrieb Steve Dower: > You'll only need to rebuild the _ssl and _hashlib extension modules > with the new OpenSSL version. The easiest way to do this is to build > from source (which has already been updated for 1.0.1h if you use the > externals scripts in Tools\buildbot), and yo

Re: [Python-Dev] VC++ 2008 Express Edition now locked away?

Am 07.03.13 09:53, schrieb Steve Dower: To use the SDK compiler, you need to do a few manual steps first. After starting a command window, you need to run a batch file to configure your environment. Choose the appropriate option from C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\bin\vcv

Re: [Python-Dev] Slides from today's parallel/async Python talk

Am 14.03.13 11:23, schrieb Trent Nelson: ARM CPUs don't have segment registers because they have a simpler addressing model. The register CP15 came up after a couple of Google searches. Noted, thanks! Yeah that's my general sentiment too. I'm definitely curious to see if other

Re: [Python-Dev] About issue 6560

Am 14.03.13 15:15, schrieb Ani Sinha: I was looking into a mechanism to get the aux fields from recvmsg() in python and I came across this issue. Looks like this feature was added in python 3.3. Is there any reason why this feature was not added for python 2.7? Most certainly: Python 2.7 (and t

Re: [Python-Dev] Slides from today's parallel/async Python talk

Am 14.03.13 12:59, schrieb Stefan Ring: I think you should be able to just take the address of a static __thread variable to achieve the same thing in a more portable way. That assumes that the compiler supports __thread variables, which isn't that portable in the first place. Regards, Martin

Re: [Python-Dev] Slides from today's parallel/async Python talk

Am 15.03.13 00:19, schrieb Antoine Pitrou: Does Microsoft change their recommendations every couple of years? :) Indeed they do. In fact, it's not really the recommendation that changes, but APIs that are added to new Windows releases. In the specific case, Windows 8 adds an API called "Regis

Re: [Python-Dev] The end of 2.7

Am 07.04.13 00:37, schrieb Benjamin Peterson: > What I like about 6 months is that its short enough, so we don't have > feel bad about not taking a certain change; it can just be pushed to > the next no-too-far-away release. A year is quite a while to wait for > a fix to be released. It's also a ni

Re: [Python-Dev] The end of 2.7

Am 07.04.13 11:46, schrieb Tshepang Lekhonkhobe: > On Sun, Apr 7, 2013 at 9:13 AM, Maciej Fijalkowski wrote: >> For what is worth, we'll maintain the stdlib part of 2.7 past 2 years. > > You mean 2 years beyond 2015 (assuming that will be end-of-bugfix date)? No, I think he means "beyond 2 years

Re: [Python-Dev] The end of 2.7

Am 07.04.13 16:58, schrieb Gregory P. Smith: > We don't need to close the 2.7 branch to commits and bug fixes. Ever. I wouldn't want this to happen, actually. People making changes to the 2.7 branch will want to see them released some day. The expectation is on the release people to actually make

Re: [Python-Dev] The end of 2.7

> But perhaps we could change the focus for 2.7 development a bit: > instead of fixing bugs (or bickering about whether something is a bug > fix or a new feature) we could limit changes to ensuring that it works > on newer platforms. Martin mentioned that building 2.7 for Windows > with the same to

Re: [Python-Dev] 2.7.5 baking

Am 15.05.13 20:07, schrieb Georg Brandl: > Has anybody heard from Martin recently? I hope he's well and just > overworked... True on both accounts. I was travelling over the weekend, and then didn't manage to catch up with email. Sorry for the delay. Regards, Martin ___

Re: [Python-Dev] [RELEASED] Python 2.7.5

Am 16.05.13 10:42, schrieb Ben Hoyt: > FYI, I tried this just now with Python 2.7.4 running, and the > installer nicely tells you that "some files that need to be updated > are currently in use ... the following applications are using files, > please close them and click Retry ... python.exe (Proc

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

Am 21.05.13 18:03, schrieb Ethan Furman: > And, of course, we only make these changes when we're already modifying > the module for some other reason. In the specific case, the KeyError has indeed useful information that the TypeError does not, namely the specific character that is the culprit. S

Re: [Python-Dev] Structural cleanups to the main CPython repo

Am 28.05.13 15:07, schrieb Nick Coghlan: >> Sounds fine (I don't like "Apps" much, but hey :-)). > > Unfortunately, I don't know any other short word for "things with main > functions that we ship to end users" :) Bike-sheddingly: POSIX calls them "commands and utilities": https://www2.opengroup

Re: [Python-Dev] Structural cleanups to the main CPython repo

Am 28.05.13 18:20, schrieb Antoine Pitrou: > Le Tue, 28 May 2013 23:07:37 +1000, > Nick Coghlan a écrit : >> It was deliberate - a big part of PEP 432 is making sure that all the >> interpreter state lives *in* the interpreter state (as part of the >> config struct). > > It sounds a bit exagerat

Re: [Python-Dev] lament for the demise of unbound methods

Am 05.07.13 11:23, schrieb Michael Foord: > I've also lamented the death of bound methods in Python 3 for mock > "autospeccing". Autospec introspects objects and provides mock > objects with the same attributes - and with the same method > signatures. I wonder why you need to figure out the signat

Re: [Python-Dev] lament for the demise of unbound methods

Am 04.07.13 18:42, schrieb Chris Withers: > Hi Guido, > > I've bumped into this a couple of times. > > First time was when I wanted to know whether what I had was a > classmethod, staticmethod or normal method here: > > https://github.com/Simplistix/testfixtures/blob/master/testfixtures/replace.

Re: [Python-Dev] Accepting PEP 445

Am 07.07.13 01:04, schrieb Victor Stinner: > 2013/7/6 Antonio Cavallo : >> Could that remove the need for the --with-pydebug flag? > > With the PEP 445, you still have to recompile Python with > --with-debug, but you don't have to recompile Python extensions > anymore. Really? What about _PyObje

Re: [Python-Dev] Python 3.4 and Windows XP: just 45 days until EOL

Am 12.07.13 01:58, schrieb Christian Heimes: > For Python 3.4 is going to be a very close call. According to PEP 429 > 3.4.0 final is scheduled for February 22, 2014. The extended support > phase of Windows XP ends merely 45 days later on April 8, 2014. Do we > really have to restrict ourselves to

Re: [Python-Dev] Adding Python scripts to PATHEXT on Windows

Am 15.07.13 10:26, schrieb Paul Moore: > Does anyone have any objections to this? I could try to write a patch, > but I know next to nothing about building MSIs, so if any of the > installer experts could help that would be fantastic. It's fine with me. I could write the patch, but will likely for

Re: [Python-Dev] Python 3 as a Default in Linux Distros

Am 24.07.13 11:12, schrieb Bohuslav Kabrda: > - Should we point /usr/bin/python to Python 3 when we make the move? This should depend on the answer to this question: - for how long have you been providing /usr/bin/python2 binaries? Users "should" have been explicit in declaring scripts as /usr/bi

Re: [Python-Dev] Python 3 as a Default in Linux Distros

Am 24.07.13 17:56, schrieb Lennart Regebro:> On Wed, Jul 24, 2013 at 3:54 PM, Lennart Regebro wrote: >> On Wed, Jul 24, 2013 at 11:12 AM, Bohuslav Kabrda wrote: >>> - Should we point /usr/bin/python to Python 3 when we make the move? >> >> No. > > To be more explicit. I think it's perfectly fine

Re: [Python-Dev] MyOpenID.com no longer supported

Am 29.07.13 18:56, schrieb R. David Murray: > Either Martin needs to clue me in, or I'll have to find time to read > his openid code :) If you want to read the code, this issue can be discovered from schema.py. The openids are stored per user in a single field; multiple openids are simply space-se

Re: [Python-Dev] Adding Python scripts to PATHEXT on Windows

Am 28.07.13 00:36, schrieb Paul Moore: > On 27 July 2013 21:14, Steve Dower > wrote: > > Any chance of this being made optional when installing? It provides > no benefit for people who prefer to associate scripts with an editor > and may be a source o

Re: [Python-Dev] PEP 442 aftermath: module globals at shutdown

Am 30.07.13 23:32, schrieb Antoine Pitrou: > - it is held alive by a C extension: the main example is the locale > module, which is held alive by _io and in turn keeps alive other > Python modules (such as collections or re). If the _locale module would use PEP 3121 (issue15662), this problem

Re: [Python-Dev] unicodedata module is out of date

Am 06.09.13 17:55, schrieb Andrew Miller: > Are there plans to add the extra data from the other UCD files to this > module? At the moment I am using a module from > https://gist.github.com/anonymous/2204527 to obtain the script of a > character but it would be nice if this was available from the

Re: [Python-Dev] unicodedata module is out of date

Am 06.09.13 20:24, schrieb Terry Reedy: >> In Python 2.7.5 it is set to '5.2.0' so it looks as though this version >> is no longer being updated. > > In general, new features do not go into bugfix releases (x.y.z, where z >>= 1). Updating the unidate_version add new features to the unicodedata > m

Re: [Python-Dev] DTRACE support

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 06.09.13 17:14, schrieb Guido van Rossum: > I've heard good things about DTRACE but never used it myself. > > Do I understand correctly that you have to build a separate Python > executable with it turned on? My understanding is that you would no

Re: [Python-Dev] Offtopic: OpenID Providers

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 05.09.13 19:31, schrieb Jesus Cea: > What are you using?. bugs.python.org admins could share some data? Most users use one of the large services: https://www.google.com 3326 https://login.launchpad.net 335 https://*.myopenid.com 253 https://launch

Re: [Python-Dev] Add a "transformdict" to collections

Am 10.09.13 14:35, schrieb Antoine Pitrou: >> ['FOO'] or ['foo']? Both answers are justifiable. Both are possibly >> even useful depending on context... > > I think it would be best to leave it as an implementation detail, > because whichever is easiest to implement depends on the exact > implemen

Re: [Python-Dev] Add a "transformdict" to collections

Am 11.09.13 15:04, schrieb Antoine Pitrou: > There are not many possible APIs to create case-insensitive dicts, or > identity dicts. That is certainly not true. Most obviously, you have the choice of a specialized case-mapping dict, or a generalized type that can be used for case mapping also. Do

Re: [Python-Dev] Compiler for the Mac OS X version of Python 3.4

Am 18.09.13 08:43, schrieb Gregory P. Smith: > Just drop support for 10.6 with Python 3.4. Problem solved. People on > that old of a version of the OS can build their own Python 3.4 or do the > right thing and upgrade or just install Linux. > > This isn't Windows. Compiler tool chains are freely a

Re: [Python-Dev] Compiler for the Mac OS X version of Python 3.4

Am 15.09.13 00:56, schrieb Ryan: > +1. A 10.6-only build makes sense. I'd like to support Russell's point: this could put a burden on everyone releasing extension modules to also provide two binary releases, which e.g. would then mess up downloads from PyPI. So -1. +0 on dropping 10.6 support fro

Re: [Python-Dev] asdl.py and Python-ast.[hc]

Am 26.09.13 15:52, schrieb Eli Bendersky: > * Should I always check-in Python-ast.h and Python-ast.c when I touch > asdl* ? The generated files are unchanged, it's only the timestamp that > changed. If they really didn't change, I don't think it matters much. I believe there is a fundamental probl

Re: [Python-Dev] asdl.py and Python-ast.[hc]

Am 26.09.13 23:00, schrieb Antoine Pitrou: > Here you are: > http://buildbot.python.org/all/builders/AMD64%20Snow%20Leop%203.x/builds/28/steps/compile/logs/stdio > > Of course, when it's using "-jN" there may be a race condition :-) Could you make "make touch" a separate build step? Regards, Ma

Re: [Python-Dev] PEP 453 (pip bootstrapping) ready for pronouncement?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 25.09.13 23:33, schrieb Donald Stufft: > An early draft of this did not have the backport to 2.7 and when I > showed *that* version around to get feedback people were less > enthusiastic about it and generally viewed it as "nice but > worthless to m

Re: [Python-Dev] PEP 453 (pip bootstrapping) ready for pronouncement?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 30.09.13 13:18, schrieb Donald Stufft: > Well the point we tried to get across in the PEP is that a normal > feature you can typically just install a backport from PyPI to gain > it early. This isin't so much driven by "well it'd be nice for the > s

Re: [Python-Dev] cpython (2.7): Add fake buildbottouch target.

Am 30.09.13 20:11, schrieb Antoine Pitrou: > On Mon, 30 Sep 2013 16:18:57 +0200 (CEST) > martin.v.loewis wrote: >> http://hg.python.org/cpython/rev/c1a294bbb4fa >> changeset: 85882:c1a294bbb4fa >> branch: 2.7 >> parent: 85877:dd55d54b2a15 >> u

Re: [Python-Dev] Make str/bytes hash algorithm pluggable?

Am 05.10.13 01:27, schrieb Victor Stinner: > Ok, but why should we invest time to fix this specific DoS wheras > there are other DoS like XML bomb? That is a question about the very mechanics of free software. "We" don't need to invest time into anything (and you may have noticed that I lately act

Re: [Python-Dev] GC pauses in CPython

Am 14.10.13 13:49, schrieb Maciej Fijalkowski: > I'm working on an incremental GC for PyPy. How do I measure GC pauses > in CPython? (that is, the circular reference searching stuff) I would instrument the interpreter. The tricky part may be to subtract the time for any resulting finalization (and

Re: [Python-Dev] non-US zip archives support in zipfile.py

Am 15.10.13 10:53, schrieb Daniel Holth: > FYI zipfile does do UTF-8 > (http://hg.python.org/cpython/file/d7ebe03fa752/Lib/zipfile.py#l368). > Only the non-Unicode encodings might need some help. I like that the > patch is only concerned with decoding. Is it necessary to support > writing non-UTF8

Re: [Python-Dev] non-US zip archives support in zipfile.py

Am 15.10.13 14:49, schrieb Daniel Holth: > It is part of the ZIP specification. CP437 or UTF-8 are the two > official choices, but other encodings happen on Russian, Japanese > systems. Indeed. Formally, the other encodings are not supported by the ZIP specification, and are thus formally misuse o

Re: [Python-Dev] Python-acceleration instructions on ARM

> ARM is specifically claiming that these instructions can be used to > accelerate Python interpretation. > > > Wow, really? One of the links below mention that? I'm skeptical though that you can really produce speedups for CPython, though; ISTM that they added Python only as a front-end

Re: [Python-Dev] Python-acceleration instructions on ARM

> - fast instance variables: likewise, with R10 holding the this > pointer. Not applicable to Python, since there is no byte code > for instance variable access. Follow-up: this could be used to JIT LOAD_CONST efficiently, though, putting co_consts into R10. Regards, Martin __

Re: [Python-Dev] Python-acceleration instructions on ARM

Antoine Pitrou wrote: > Martin v. Löwis v.loewis.de> writes: >> - efficient array indexing: they give shift-and-index back to >> Thumb mode, for a shift by 2, allowing to index arrays with >> 4-byte elements in a single instruction (rather than requiring >>

Re: [Python-Dev] Python-acceleration instructions on ARM

> At least IA32 and AMD64 have specific addressing modes where > it's possibile to use a multiplying factor of 1, 2, 4 or 8 for the > index register. > > I hope that compilers were smart enough to already used them. For x86, certainly (at least GCC does). For Thumb, certainly not: the compiler ca

Re: [Python-Dev] python seg faults

> So I am not sure where the error is. Any clue on where the bug possibly > may be: adns-python, pynids or python? Or how I should I go about > debugging this? This is out of scope for python-dev, but I give some clues anyway: - try finding out what kind of object is being released. Is it a good

Re: [Python-Dev] Tracker archeology

>> Oh, I realized that there is a component called "Unicode". So it should be >> possible to write a request to list all issues related to unicode. > > Nice, I'll add set this component for issues that don't have it. I can > still add people to these issues, if they want. We can also add more com

Re: [Python-Dev] Tracker archeology

> Now, getting into pie-in-the-sky territory, if someone (not logged in) > was to download all issues for scrapping and feeding to a local > database, what time of day would be less disastrous for the server? :) I think HTML scraping is a really bad idea. What is it that you specifically want to

Re: [Python-Dev] Tracker archeology

> For starters, free form searches, aggregation and filtering of > results. What is "free form searches" (example)? What is aggregation? What results do you want to filter? (roundup can already filter results quite well) > The web interface is pretty good for handling individual > issues, but not

Re: [Python-Dev] Tracker archeology

> Send emails before they were done :D Again: what's that? > Use a VCS for in-progress activities Hmm. Why do you need a database copy for that? > Figure out how to serialize and submit the work done locally Again, don't understand. too brief. > Share results with interested parties off-t

Re: [Python-Dev] Adding T_SIZET to structmember.h

> Mark, the patch is not trivial, I cannot spend time on this until this > is accepted. Hope you understand. I certainly do understand. So it's likely not going to happen. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.pyt

Re: [Python-Dev] RELEASED Python 3.0.1

> Any chance of getting a Mac installer for this one? Chances are non-zero, yes. Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/

Re: [Python-Dev] The fate of 3.0.*

Benjamin Peterson wrote: > Are we going to keep developing the 3.0 maintenance branch in > expectation of releasing 3.0.2 sometime or will we just focus our > efforts on 3.1? Traditionally, we had one last bugfix release after then next feature release. So I think we should release 3.0.2 right aft

Re: [Python-Dev] OS X Installer for 3.0.1 and supported versions

> (This may well have > been discussed before so my apologies if I am covering old ground here.) There might have been discussions on pythonmac lists, but no recent ones on python-dev, AFAIR. > The last Apple point release of 10.3 was in 4/2005. 10.4 was also > released then. [...] Needless t

Re: [Python-Dev] Tracker archeology

> But no way to share aggregated search results (I've sent some > off-list), 'follow' users (i.e., be added as nosy for issues where > user A is nosy), auto-add as nosy based on keywords, etc. Someday we > could have these nosy features hosted externally, e.g. as an AppEngine > app that subscribes

Re: [Python-Dev] OS X Installer for 3.0.1 and supported versions

> A single installer could support both 32-bit on 10.4 and 64-bit on > 10.5, but I don't think that's very useful because there are changes > in the low-level unix API's that could result in different behaviour > of a 32-bit and 64-bit script on the same system. In general 10.5 has > much saner U

Re: [Python-Dev] Irix still supported? (was Re: Tracker archeology)

Terry Reedy wrote: > Guido van Rossum wrote: >> Irix is long dead and we don't support it in any form or version. > > I closed the tracker issue. I will let Martin update PEP11. I think you misunderstand the purpose of PEP 11. It is not meant as a repository of platforms not longer supported, bu

Re: [Python-Dev] OS X Installer for 3.0.1 and supported versions

Ronald Oussoren wrote: > > On 14 Feb, 2009, at 19:04, Martin v. Löwis wrote: > >>> A single installer could support both 32-bit on 10.4 and 64-bit on >>> 10.5, but I don't think that's very useful because there are changes >>> in the low-level unix

Re: [Python-Dev] OS X Installer for 3.0.1 and supported versions

> That's fine as long as the distutils issue is resolved. I don't think this should be a prerequisite. As Ronald says: no fix without a bug report; if the system is capable of building the extension correctly, it should do so (so it's a bug and fixes can be backported to 2.6) Regards, Martin

Re: [Python-Dev] No 2.x->3.x porting documentation?

> I'm making a naive stab at converting nose to Python3 so I can hopefully run > the lockfile test cases under Python 3. (Again, I'm offline and have no > idea at this point if it's been done already.) I ran 2to3 then tried > installing. I got an immediate error about the compiler.consts module

Re: [Python-Dev] Adding T_SIZET to structmember.h

> Martin, I was not clear enough. Please, just tell me: Do you believe > that this addition do make sense? Would you reject it for some reason > (other than a bad patch) ? I would be +0. All other integral types support both signed and signed fields, why not size_t. Regards, Martin __

Re: [Python-Dev] Tracker cleanup roadmap

> Let's improve the tracker UI to better fit our needs. Then, classify > them bugs and separate garbage from real development. Lastly, bug > reporters should get a better UI. That's it, any help is welcome. The plan sounds great. I can help with the deployment aspects (reviewing tracker patches,

Re: [Python-Dev] 30-bit PyLong digits in 3.1?

> I'd like to get this in for 3.1. Any objections or comments? Can you please upload it to Rietveld also? > Is this PEP territory? I don't think so. Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/pyth

Re: [Python-Dev] Tracker cleanup roadmap

> I have been mostly a silent spectator around and would like to chip in. > Need some initial throttle(help) for the full-fledged attack :) Please take a look at the meta tracker. It has various open issues, many open for many months now. Please tackle one that can be fixed through patches to the

Re: [Python-Dev] To 3.0.2 or not to 3.0.2?

> this will use externals, (see > http://svn.python.org/projects/distutils/trunk/) This I don't understand. There is file named EXTERNALS.txt, but I don't understand its purpose. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http:

Re: [Python-Dev] To 3.0.2 or not to 3.0.2?

> Let me know if this is not wanted. I can drop it it's no big deal. That is fine with me. I was worried that you might have made Lib/distutils external, which I would not have liked. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org htt

Re: [Python-Dev] Attention Bazaar mirror users

> I didn't say "from source", I said "from a VCS checkout". If using a > *specific* recent official release of a core tool is bureaucratically > infeasible, it would IMO be very unusual if you're allowed to checkout > and build arbitrary versions of Python, rather than using a version > provided b

Re: [Python-Dev] Attention Bazaar mirror users

> You're ignoring the second paragraph quoted above. I'm *not* denying > that such environments are common. The question is "Do developers > *restricted to such environments* really have an impact on Python > development to outweigh the real cost of standardizing on an older > implementation of B

Re: [Python-Dev] Attention Bazaar mirror users

> Wouldn't such hypothetical core Python developers be able to build and > run their own local copy of bzr, using that self-compiled Python? It has been hypothetical for a while, but it never was about core developers. Regards, Martin ___ Python-Dev ma

Re: [Python-Dev] Attention Bazaar mirror users

> I'm *not* ignoring them; I'm stating a strong belief that the great > majority of them will not be adversely affected by this change. Since > almost by definition they're not likely to speak up very much, I'm > happy to hear arguments from a qualified observer (such as yourself) > on their behal

Re: [Python-Dev] Attention Bazaar mirror users

> This has been true for a number of cases over the years: whether the > "repostiory format", or the wire protocol, sometimes changes which > materially *improve* the user's experience may require upgrading the > client on the user's machine. In the case of SVN, upgrading to 1.5 gets > vastly be

Re: [Python-Dev] Reviving restricted mode?

> I've already been maintaining the PJE-inspired ctypes-based approach > and monkeypatches for various Python versions for a while now. See > secure.py, secure25.py, secure26.py and secure30.py in: > > > http://github.com/tav/plexnet/tree/9dabc570a2499689e773d1af3599a29102071f80/source/plexnet/

Re: [Python-Dev] gdbinit and Gdb wrapper objects

> I am trying to use python gdb to debug a python process that is hanginig > - it is a thread lock situation. Larry, python-dev is a mailing list for the development of Python, not the development with Python. So this question is off-topic. > 1) Does anyone have any idea why this might be happen

Re: [Python-Dev] Reviving restricted mode?

> Could one of you please review: > > http://codereview.appspot.com/20051 > > The patch is a mere 6 lines of code and provides the absolute minimum > that is needed to secure the Python interpreter! Unlike Guido, I'm not quite willing to your word for it. OTOH, the patch looks harmless (with

Re: [Python-Dev] Reviving restricted mode?

> And, here's a version for Python 2.6+ -- diffed against an svn > checkout of the current python/trunk: > > http://codereview.appspot.com/21051/show > > Please review also. Cheers! No need to provide two versions. Regular back-merging should be able to deal with that just fine. Regards, Mart

Re: [Python-Dev] Challenge: Please break this! [Now with blog post]

> Don't I remember the previous restricted module dying a similar "death > of 1,000 cuts" before it was concluded to be unsafe at any height and > abandoned? I think you are slightly misremembering. It got cut again and again, but never died. Then, new-style classes hit an artery, and it bled to d

Re: [Python-Dev] Patch Ready for review

> I am wondering what to expect next. How long will it be before it is > applied etc. This is my first attempt to submit a patch to Python. Unfortunately, it may take any time between a day and five years, see below. > Also, does anyone know who the main person is for running changes to the > c

Re: [Python-Dev] OS X Installer for 3.0.1 and supported versions

> Do Python 2.6 and 3.0 support building with Tcl/Tk 8.5? Yes, that works fine. The Windows binaries ship with 8.5, and there weren't any complaints (in this respect). Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python

Re: [Python-Dev] PEP 372 -- Adding an ordered directory to collectionsready for pronouncement

> This strict interpretation is violated all the time in OO programming; > consider e.g. the common overriding of object.__repr__. (In fact, even > the definition of dict.__eq__ overriding object.__eq__ would validate > it.) AFAIK a more common use of the term in OO languages is about > signatures

Re: [Python-Dev] draft 3.1 release schedule

> Would whoever is responsible for IDLE please take a look at the patches > I submitted for Python 2 & 3 [tracker IDs 5233 and 5234 respectively]. > These change the behavior of IDLE so that IDLESTARTUP or PYTHONSTARTUP > files are executed with each restart. This allows loading frequently > used p

Re: [Python-Dev] PEP 372 -- Adding an ordered directory to collections ready for pronouncement

> Is it a class or function? What does it do? Can the English as second > language folks guess what the o stands for? Is it a builtin or pure > python? My guess is that the experiment will be informative. I'll do that tomorrow (if I manage to remember). My guess is that "ordered dictionary" is

Re: [Python-Dev] draft 3.1 release schedule

> So what is the solution? In the specific case, I don't know. I recall that somebody offered to pick up the change. I really didn't mean to suggest that the patch will remain unnoticed - it was just a warning that it *might* remain unnoticed. The more general issue is that of patches being unrev

Re: [Python-Dev] patch commit policies (was [issue4308] repr of httplib.IncompleteRead is stupid)

> That aside, is it actually a python-wide policy to *forbid* patching > older releases where the patch isn't security-related? I set this policy for the releases I manage, namely 2.4 and 2.5. I still plan to write a PEP on security releases, and how they relate to maintenance releases. > I can

Re: [Python-Dev] Integrate lxml into the stdlib?

> I do see the point you are making here. Even if lxml gets mature and > static, that doesn't necessarily apply to the external libraries it uses. > However, I should note that exactly the same argument also applies to > sqlite3 and gdbm, which, again, are in the stdlib today, with sqlite3 being >

Re: [Python-Dev] draft 3.1 release schedule

> I hope that somebody will pick up the slack here, because review is > really important to the workflow, and getting more people involved in > reviewing at some level is more important (because it's less > glamorous in itself) than attracting coders. Ok, then let me phrase it this way: if somebod

Re: [Python-Dev] draft 3.1 release schedule

> I guess I'm saying that I'm surprised people aren't a bit more > appreciative of the opportunity to review code. Not sure what "people" you are referring to here which aren't appreciative of the opportunity to review code. Committers? Non-committers? > I don't think I would even be on this lis

Re: [Python-Dev] patch commit policies (was [issue4308] repr of httplib.IncompleteRead is stupid)

> If it is possible for a hostile outsider to trigger the DOS by sending > mail to be processed by an application using the library, and the > application can't avoid the DOS without ditching / forking / > monkeypatching the library, then I would call the bug a "security bug", > period. IIUC, it w

Re: [Python-Dev] Python wins Linux New Media Award for Best Open Source Programming Language

>> The prize was Martin von Löwis of the Python Foundation on behalf of the >> Python community itself. > > This is a funny translation from German-to-English. :-) > > But yeah, a good one and the prize was presented by Klaus Knopper of Knoppix. > > Congratulations! Actually, the prize went to

Re: [Python-Dev] Windows 2.6.1 installer - msiexec not creating msvcr90.dll

charlie wrote: > I am trying to script a Python installation on Windows, using msiexec > from the windows cmd prompt. I do not want to register extensions. > > I have tried all the combinations I can find on the following page: > http://www.python.org/download/releases/2.5/msi/ > > But, no matter

Re: [Python-Dev] Integrate lxml into the stdlib?

> Interesting. I assume you are referring to Windows here, right? Does that > "just work" because the DLL is in the same directory? Correct. Also, because changes to SQLite don't change the API, just the implementation. Regards, Martin ___ Python-Dev ma

Re: [Python-Dev] Integrate lxml into the stdlib?

>> DLLs/sqlite3.dll 557K > > This is sqlite3 itself. I am presuming that the phrase "replace the > sqlite DLL" above refers to this one Correct. > -- although the same argument actually holds for the .pyd file Not quite. You can download Windows binaries for newer sqlite versions from sqlite.or

Re: [Python-Dev] Integrate lxml into the stdlib?

> I see. I didn't realize you were talking about adding your own files > to these directories. I have no idea; the best way to find out is to > experiment. I could see the default policy of Windows installers go > either way. An upgrade installation removes all old files it installed (the old MSI

Re: [Python-Dev] Forgotten Py3.0 change to remove Queue.empty() and Queue.full()

> IIRC, that was the rationale for cmp() removal in 3.0.1. And indeed, that removal already caused a bug report and broke the efforts of SWIG to support Python 3.0. I disagree that our users are served by constantly breaking the API, and removing stuff just because we can. I can't see how removin

Re: [Python-Dev] Forgotten Py3.0 change to remove Queue.empty() and Queue.full()

>> I disagree that our users are served by constantly breaking the >> API, and removing stuff just because we can. I can't see how >> removing API can possibly serve a user. > > Am not following you here. My suggestion was to remove the two > methods in Py3.1 which isn't even in alpha yet. Your

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