On Tue, Nov 26, 2019 at 12:00 PM Brett Cannon wrote:
> Python 3.9 is going to be the first release which will exist without any
> Python 2.7 overlap. Does this mean we are ready to start removing things
> that have been deprecated since at least Python 3.7? PEP 4 says [we are in
> the clear for m
On Wed, Nov 27, 2019 at 10:15 AM Brett Cannon wrote:
> Gregory P. Smith wrote:
> > On Tue, Nov 26, 2019 at 12:00 PM Brett Cannon br...@python.org wrote:
> > > Python 3.9 is going to be the first release which
> > > will exist without any
> > > Python 2.7 ove
On Tue, Dec 3, 2019 at 8:21 AM Mark Shannon wrote:
> Hi Everyone,
>
> I am proposing a new PEP, still in draft form, to impose a limit of one
> million on various aspects of Python programs, such as the lines of code
> per module.
>
> Any thoughts or feedback?
>
> The PEP:
> https://github.com/ma
I'd prefer it if we stayed on topic here...
On Fri, Dec 6, 2019 at 3:15 PM Chris Angelico wrote:
> On Sat, Dec 7, 2019 at 9:58 AM Greg Ewing
> wrote:
> >
> > On 7/12/19 2:54 am, Rhodri James wrote:
> >
> > > You've talked some about not making the 640k mistake
> >
> > I think it's a bit unfair
My overall problem with the PEP and a reason I'd reject it by default it
that it is asking to pre-emptively impose limits on things, some of which
we believe would cause problems to existing long running applications
(limiting the total number of types for example), without having actually
demonstr
I personally think we shouldn't worry about it. I *try* to use an autoconf
version at least as recent as what was used for the current file, but
beyond that it is unlikely anything depends on autoconf distroisms within
our own in tree configure.
Forcing humans to do weird tricks (always guaranteed
On Mon, Dec 16, 2019 at 11:11 AM Steve Dower wrote:
> On 13Dec2019 0959, Brett Cannon wrote:
> > Steve Dower wrote:
> >> If people are generally happy to move PR builds/checks to GitHub
> >> Actions, I'm happy to merge https://github.com/zooba/cpython/pull/7
> >> into
> >> our active branches (wi
On Tue, Dec 17, 2019 at 12:30 PM Kacvinsky, Tom
wrote:
> We ran into an issue where having the SQLite library built with
> -DSQLITE_THREADSAFE=0,
> but then the sqlite3 module (really, the _sqlite3.so0 crashing in
> threading code. So I have
> to ask if it is intended that the sqlite3 Python mo
On Wed, Jan 1, 2020 at 6:40 AM Andrew Svetlov
wrote:
> __del__ is very useful not for interpreter shutdown but as a regular
> destructor in object's lifecycle.
>
The reason we should warn people against ever implementing __del__ is that
people rarely actually understand object lifecycle. Its pr
+1 remove it to match that policy. I find it unlikely someone will ask for
it to be restored, but our first response before doing so should be to see
if they can instead use it as a dependency via PyPI: Someone who wants to
maintain it for future use can take 3.8 formatter module and put it there.
e for upgrading us to 3.9 so we'd simply make
that happen at that time)
-gps
On Fri, Jan 17, 2020 at 11:09 AM Gregory P. Smith wrote:
> +1 remove it to match that policy. I find it unlikely someone will ask
> for it to be restored, but our first response before doing so should be to
&
Nice PEP! That this discussion wound up in the NP-complete "naming things"
territory as the main topic right from the start/prefix/beginning speaks
highly of it. :)
The only things left I have to add are (a) agreed on don't specify if it is
a copy or not for str and bytes.. BUT (b) do specify that
On Tue, Mar 24, 2020 at 11:55 AM Brett Cannon wrote:
> -1 on "cut*" because my brain keeps reading it as "cute".
> +1 on "trim*" as it is clear what's going on and no confusion with
> preexisting methods.
> +1 on "remove*" for the same reasons as "trim*".
>
> And if no consensus is reached in thi
On Wed, Apr 15, 2020 at 12:49 PM Ivan Pozdeev via Python-Dev <
python-dev@python.org> wrote:
> First of all, be aware of the limitations of this approach (which will
> need to be clearly documented if we go this way):
>
>- It only allows valid Python identifiers -- while JSON accepts any
>
On Wed, Apr 15, 2020 at 7:37 AM Victor Stinner wrote:
> Le mer. 15 avr. 2020 à 05:02, Raymond Hettinger
> a écrit :
> > I would like to make that functionality available to the JSON module (or
> just about anything else that accepts a custom dict) by adding the magic
> methods for mappings so th
On Tue, Apr 21, 2020 at 10:49 AM Antoine Pitrou wrote:
> On Tue, 21 Apr 2020 18:46:04 +0200
> Petr Viktorin wrote:
> > On 2020-04-21 11:01, Antoine Pitrou wrote:
> > > On Mon, 20 Apr 2020 19:21:21 -0600
> > > Eric Snow wrote:
> > >> Honest question: how many C extensions have process-global sta
Could we go ahead and mark lib2to3 as Pending Deprecation in 3.9 so we can
get it out of the stdlib by 3.11 or 3.12?
lib2to3 is the basis of all sorts of general source code manipulation
tooling. Its name and original reason d'etre have moved on. It is
actively used to parse and rewrite Python 3
On Tue, Apr 21, 2020 at 9:35 PM Gregory P. Smith wrote:
> Could we go ahead and mark lib2to3 as Pending Deprecation in 3.9 so we can
> get it out of the stdlib by 3.11 or 3.12?
>
I'm going ahead and tracking the idea in https://bugs.python.org/issue40360.
>
> lib2to3 is th
On Wed, Apr 29, 2020 at 5:40 AM Julien Salort wrote:
> Le 29/04/2020 à 03:18, Eric Snow a écrit :
>
> > My (honest) question is, how many folks using subinterpreters are
> > going to want to use numpy (or module X) enough to get mad about it
> > before the extension supports subinterpreters? Wha
On Mon, May 4, 2020 at 9:45 AM Steve Dower wrote:
> For those who haven't looked in a while, the uuid module uses ctypes to
> look up libuuid for uuid_generate_time_safe() and uuid_generate_time()
> functions.
>
> I've run into scenarios where I need to remove this from our own builds,
> but it s
On Wed, May 6, 2020 at 1:14 PM Serhiy Storchaka wrote:
> 06.05.20 00:46, Victor Stinner пише:
> > Subinterpreters and multiprocessing have basically the same speed on
> > this benchmark.
>
> It does not look like there are some advantages of subinterpreters
> against multiprocessing.
>
There is
On Fri, May 15, 2020 at 11:55 AM Henk-Jaap Wagenaar <
wagenaarhenkj...@gmail.com> wrote:
> I'll join in with the fun...
>
> zip(strict=True) +1
> itertools.zip_strict() +0
>
Agreed. The best way to reduce accidental incorrect use of the builtin is
to make the builtin capable of doing what a peop
On Wed, May 20, 2020 at 11:09 AM Jim J. Jewett wrote:
> David Mertz wrote:
>
> > Fwiw, I don't think it changes my order, but 'strict' is a better word
> than
> > 'equal' in all those places. I'd subtract 0.1 from each of those votes if
> > they used "equal".
>
> I would say that 'equal' is worse
Sounds like a natural fit, I'd just do it for 3.10.
On Sun, May 24, 2020, 9:45 AM Eric V. Smith wrote:
> Does anyone have an opinion on https://bugs.python.org/issue39673? It
> maps ETIME to TimeoutError, in addition to the already existing ETIMEDOUT.
>
> http://man7.org/linux/man-pages/man3/err
On Wed, Jun 3, 2020 at 2:13 PM Victor Stinner wrote:
> Le mer. 3 juin 2020 à 19:17, Mark Shannon a écrit :
> > > I also *added* a bunch of *new* "getter" or "setter" functions to the
> > > public C API for my project of hiding implementation details, like
> > > making structures opaque:
> > > ht
On Tue, Jun 23, 2020 at 7:41 AM Elisha Paine wrote:
> Hi all,
>
> I am looking at getting TkDND support into tkinter, and have created
> issue40893. However, we are currently considering the practicalities of
> adding a new optional dependency to Python and I was hoping someone
> could help answe
On Wed, Jun 24, 2020 at 1:38 PM Luciano Ramalho wrote:
> Thank you Guido, Brandt Bucher, Tobias Kohn, Ivan Levkivskyi and Talin
> for this fun and very useful new feature.
>
> I do enjoy pattern matching a lot in Elixir—my favorite language these
> days, after Python.
>
> I don't want to start a
On Wed, Jun 24, 2020 at 7:34 PM Taine Zhao wrote:
> > e.g., "or", and then I wonder "what does short-circuiting have to do
> > with it?". All reuse of symbols carries baggage.
>
> "or" brings an intuition of the execution order of pattern matching, just
> like how people already know about "short
On Wed, Jun 24, 2020 at 7:58 PM Stephen J. Turnbull <
turnbull.stephen...@u.tsukuba.ac.jp> wrote:
> Ethan Furman writes:
>
> > _ does not bind to anything, but of what practical importance is that?
>
> *sigh* English speakers ... mutter ... mutter ... *long sigh*
>
> It's absolutely essential to
On Thu, Jun 25, 2020 at 6:49 PM Raymond Hettinger <
raymond.hettin...@gmail.com> wrote:
> > it is hard to make a decision between the pros and cons,
> > when the pros are in a single formal document and the
> > cons are scattered across the internet.
>
> Mark, I support your idea. It is natural f
Litmus test: Give someone who does not know Python this code example from
the PEP and ask them what it does and why it does what it does:
match get_shape():
case Line(start := Point(x, y), end) if start == end:
print(f"Zero length line at {x}, {y}")
I expect confusion to be the result
On Fri, Jun 26, 2020 at 6:42 AM Mark Shannon wrote:
>
> > Let us start from some anecdotal evidence: isinstance() is one of the
> most called functions in large scale Python code-bases (by static call
> count). In particular, when analyzing some multi-million line production
> code base, it was d
On Fri, Jul 17, 2020 at 10:41 AM Pablo Galindo Salgado
wrote:
> I like the proposal in general but I am against removing lnotab. The
> reason is that many tools rely on reading this attribute to figure out the
> Python call stack information. For instance, many sampler profilers read
> this memor
On Fri, Jul 17, 2020 at 8:41 AM Ned Batchelder
wrote:
> https://www.python.org/dev/peps/pep-0626/ :)
>
> --Ned.
>
> On 7/17/20 10:48 AM, Mark Shannon wrote:
> > Hi all,
> >
> > I'd like to announce a new PEP.
> >
> > It is mainly codifying that Python should do what you probably already
> > thoug
On Tue, Jul 21, 2020 at 1:39 PM Gregory P. Smith wrote:
>
> On Fri, Jul 17, 2020 at 10:41 AM Pablo Galindo Salgado <
> pablog...@gmail.com> wrote:
>
>> I like the proposal in general but I am against removing lnotab. The
>> reason is that many tools rely on readin
On Wed, Jul 22, 2020 at 5:19 AM Mark Shannon wrote:
>
>
> On 21/07/2020 9:46 pm, Gregory P. Smith wrote:
> >
> >
> > On Fri, Jul 17, 2020 at 8:41 AM Ned Batchelder > <mailto:n...@nedbatchelder.com>> wrote:
> >
> > https://www
On Tue, Jul 28, 2020 at 2:12 PM Jim J. Jewett wrote:
> ah... we may have been talking past each other.
>
> Steve Dower wrote:
> > On 25Jul2020 2014, Jim J. Jewett wrote:
> > > But it sounds as though you are saying the benefit
>
> [of storing the line numbers in an external table, I thought,
> bu
On Tue, Sep 15, 2020 at 1:27 PM wrote:
> September 15, 2020 4:02 PM, "Daniel Butler" >
> wrote:
>
> > Users would be encouraged to try it but
>
> > NOT to publish code using it.
>
> Thinking out loud, macros could be enabled with a command line flag.
> Advanced users would know how to use it but
It'd be worthy of fixing in 2.6 since the module exists. Though honestly...
who cares about Irix?
On Sat, Mar 28, 2009 at 8:53 PM, R. David Murray wrote:
> I'm reviewing http://bugs.python.org/issue2591, which is marked as
> 'security' because it is a potential buffer overflow. almodule.c has
>
On Tue, Apr 28, 2009 at 8:03 PM, Larry Hastings wrote:
>
> EXECUTIVE SUMMARY
>
> I've written a patch against py3k trunk creating a new function-based
> API for creating extension types in C. This allows PyTypeObject to
> become a (mostly) private structure.
>
>
> THE PROBLEM
>
> Here's how you
On Sun, May 3, 2009 at 10:39 AM, "Martin v. Löwis" wrote:
> > If the error handler is supposed to be used for codecs other than utf-8,
> > perhaps it should renamed something more generic, e.g.
> "surrogate-escape"?
>
> Perhaps. However, utf-8b doesn't really have to do anything with utf-8 -
> it'
On Sun, May 3, 2009 at 1:27 PM, "Martin v. Löwis" wrote:
> > > If the error handler is supposed to be used for codecs other than
> > utf-8,
> > > perhaps it should renamed something more generic, e.g.
> > "surrogate-escape"?
> >
> > Perhaps. However, utf-8b doesn't really have
On Mon, May 4, 2009 at 7:33 AM, Gregor Lingl wrote:
> Hi,
>
> Encouraged by a conversation with Martin at PyCon 2009
> I've prepared a version 1.1b of the turtle module and I'd like to
> get some advice or assistance to get it into the beta as explained
> below. Thus I'd appreciate very much if a
On Thu, May 7, 2009 at 12:39 PM, "Martin v. Löwis" wrote:
>> Given your explanation of what the new 'surrogates' handler does (pass
>> rather than reject erroneous surrogates), I think 'surrogates_pass' is
>> fine. Thus, I considoer that and 'surrogates_excape' the best proposal
>> the best so fa
On Tue, Jun 2, 2009 at 1:11 PM, Jake McGuire wrote:
> The minimal demonstration of the problem of representing networks and
> addresses using the same class:
fwiw, that (hosts vs networks in the same class) is not what you are
demonstrating below. What you demonstrate is that its silly for
itera
On Tue, Jun 2, 2009 at 7:39 PM, Guido van Rossum wrote:
>
> I'm disappointed in the process -- it's as if nobody really reviewed
> the API until it was released with rc1, and this despite there being a
> significant discussion about its inclusion and alternatives months
> ago. (Don't look at me --
On Thu, Jul 2, 2009 at 2:52 AM, Jesus Cea wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Alexandre Vassalotti wrote:
>> On Wed, Jul 1, 2009 at 10:05 PM, Guido van Rossum wrote:
>>> The select module already supports the poll() system call. Or is there
>>> a special variant that only S
On Mon, Jun 29, 2009 at 2:28 PM, "Martin v. Löwis" wrote:
>> AFAIK, ignoring EINTR doesn't preclude the calling of signal handlers.
>
> This is my understanding as well - so I don't think Python actually
> "swallows" the signal.
>
>> A great example is reading from a socket. Whether or not it can b
On Sat, Jul 25, 2009 at 2:53 AM, "Martin v. Löwis" wrote:
>> This is fixed in the trunk (Revision 72880), but there has been number
>> of valid requests to backport it Python 2.6. While I agree and ready
>> to backport to Python 2.6, I would like to ask here if there are any
>> objections in this f
On Thu, Jul 23, 2009 at 4:28 PM, Thomas Wouters wrote:
>
> So attached (and at http://codereview.appspot.com/96125/show ) is a
> preliminary fix, correcting the problem with os.fork(), os.forkpty() and
> os.fork1(). This doesn't expose a general API for C code to use, for two
> reasons: it's not ea
On Mon, Jul 27, 2009 at 5:32 PM, Glyph Lefkowitz wrote:
> On Mon, Jul 27, 2009 at 3:04 PM, Paul Moore wrote:
>>
>> I like MRAB's idea of using a (non-standard) "e" flag to include
>> stderr. So "r" reads from stdout, "re" reads from stdout+stderr.
>>
>> Anything more complicated probably should ju
In particular this issue: http://bugs.python.org/issue1628205
I believe we should handle EINTR internally within the
socket._fileobject wrapper as nobody using a file-like object should
ever expect to get an EINTR. EINTR only comes from using the lowest
level system calls.
Anyone strongly disag
On Wed, Aug 12, 2009 at 9:33 AM, Thomas Wouters wrote:
>
> I replaced the RAID controller, the old data was still intact, so I brought
> the temporary machine down and the new machine up. Everything seems to work
> just fine, so happy svn-up'ing.
> (I will reboot mail.python.org for a few minutes,
On Sun, Aug 23, 2009 at 2:24 PM, "Martin v. Löwis" wrote:
> >> No doubt this is a useful functionality to have but it would be great to
> >> have some comments on whether
> >> this can be(or even should be) feasibly added as an inbuilt support.
> >
> > MvL already asked for a patch so I suppose th
On Sun, Aug 30, 2009 at 10:40 PM, Jeroen Ruigrok van der Werven <
asmo...@in-nomine.org> wrote:
> -On [20090831 06:29], Collin Winter (coll...@gmail.com) wrote:
> >Are there any applications/frameworks which have zip files on their
> >critical path, where this kind of (admittedly impressive) speed
On Sun, Aug 30, 2009 at 5:24 PM, Guido van Rossum wrote:
> On Sun, Aug 30, 2009 at 4:28 PM, Brett Cannon wrote:
> > I am going through and running the entire test suite using importlib
> > to ferret out incompatibilities. I have found a bunch, although all
> > rather minor (raising a different ex
food for thought as noticed by a coworker who has been profiling some hot
code to optimize a library...
If a function does not have a return statement we return None. Ironically
this makes the foo2 function below faster than the bar2 function at least as
measured using bytecode size:
Python 2.6.
On Mon, Aug 31, 2009 at 2:20 PM, Antoine Pitrou wrote:
> Gregory P. Smith krypto.org> writes:
> >
> > food for thought as noticed by a coworker who has been profiling some hot
> code
> to optimize a library...If a function does not have a return statement we
> retu
On Mon, Aug 31, 2009 at 5:01 PM, Greg Ewing wrote:
> Antoine Pitrou wrote:
>
> Did your coworker run any timings instead of basing his assumptions on
>> bytecode
>> size?
>>
>
> In any case, what are you suggesting -- that the last value
> returned by a function call in the body should be the
> d
On Wed, Sep 9, 2009 at 9:07 AM, Thomas Wouters wrote:
>
>
> On Sat, Jul 25, 2009 at 19:25, Gregory P. Smith wrote:
>>
>> On Thu, Jul 23, 2009 at 4:28 PM, Thomas Wouters wrote:
>> >
>> > So attached (and at http://codereview.appspot.com/96125/show ) is
On Wed, Sep 9, 2009 at 11:36 AM, Thomas Wouters wrote:
>
> On Wed, Sep 9, 2009 at 20:19, Gregory P. Smith wrote:
>>
>> Take a look at http://code.google.com/p/python-atfork/ which I created
>> to address the general fork+threading with locks held causing
>> dead
Those who feel diverse can top post.
On Sun, Oct 11, 2009 at 11:23 AM, Georg Brandl wrote:
>>> Is it really that big of an issue that we have to discuss it
>>> ad-infinitum and potentially have a quoting cop? Sometimes top-posting
>>> happens. Sometimes people don't trim messages. Sometimes peopl
On Sun, Nov 1, 2009 at 3:33 AM, Antoine Pitrou wrote:
>
> Hello again,
>
> Brett Cannon python.org> writes:
>>
>> I think it's worth it. Removal of the GIL is a totally open-ended problem
>> with no solution in sight. This, on the other hand, is a performance benefit
>> now. I say move forward wi
On Fri, Oct 23, 2009 at 1:49 AM, Nick Coghlan wrote:
> Brett Cannon wrote:
>> Another summit, another potential time to see if people want to change
>> anything about the issue tracker. I would bring up:
>>
>> - Dropping Stage in favor of some keywords (e.g. 'needs unit test',
>> 'needs docs')
>>
On Thu, Nov 5, 2009 at 4:13 PM, Yuvgoog Greenle wrote:
> On Fri, Nov 6, 2009 at 1:55 AM, Bobby R. Ward wrote:
>>
>> A switch to ENABLE those warnings?
>>
>
> I think a few people I know would still be raising strings like exceptions
> if not for the deprecation warnings. Most people won't turn on
On Mon, Dec 21, 2009 at 7:02 AM, Mark Dickinson wrote:
> In Python 2.7, PyArg_ParseTuple and friends currently accept a float
> argument where an integer is expected, but produce a
> DeprecationWarning in this case. This can be seen in various places
> in Python proper:
>
itertools.combinati
+1
My biggest concern is memory usage but it sounds like addressing that is
already in your mind. I don't so much mind an additional up front constant
and per-line-of-code hit for instrumentation but leaks are unacceptable.
Any instrumentation data or jit caches should be managed (and tunable at
On Fri, Feb 19, 2010 at 4:18 PM, P.J. Eby wrote:
> At 01:49 PM 2/19/2010 -0500, Ian Bicking wrote:
>>
>> I'm not sure how this should best work on Windows (without symlinks, and
>> where things generally work differently), but I would hope if this idea is
>> more visible that someone more opiniona
On Sat, Mar 13, 2010 at 6:00 AM, Neal Becker wrote:
> Neil Hodgson wrote:
>
>> Antoine Pitrou:
>>
>>> Is this concern still valid? We are in the 2010s now.
>>> I'm not saying I want us to put some C++ in the core interpreter, but
>>> the portability argument sounds a little old...
>>
>> There a
On Sun, Mar 14, 2010 at 4:31 AM, Nir Aides wrote:
> There are two possible problems with Dave's benchmark:
> 1) On my system setting TCP_NODELAY option on the accepted server socket
> changes results dramatically.
> 2) What category of socket servers is dave's spin() function intended to
> simulat
On Fri, Mar 26, 2010 at 5:59 PM, Michael Foord
wrote:
> Hello all,
>
> A user has suggested an optional argument to
> unittest.TestCase.assertAlmostEqual for specifying a maximum difference
> between the expected and actual values, instead of using rounding.
>
> This sounds great to me as the defa
fyi - newthreading has been picked up by lwn.
http://lwn.net/Articles/393822/#Comments
___
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/a
On Thu, Jul 8, 2010 at 12:52 PM, MRAB wrote:
> Hi all,
>
> I re-implemented the re module, adding new features and speed
> improvements. It's available at:
>
>http://pypi.python.org/pypi/regex
>
> under the name "regex" so that it can be tried alongside "re".
>
> I'd be interested in any comm
On Sun, Jul 11, 2010 at 9:28 AM, Antoine Pitrou wrote:
> On Sun, 11 Jul 2010 13:23:13 +
> Reid Kleckner wrote:
> >
> > I'm also expecting to be doing more work merging unladen-swallow into
> > the py3k-jit branch, so I was wondering if I could get commit
> > privileges for that.
>
> It sound
On Thu, Jul 22, 2010 at 9:24 AM, wrote:
> I agree with the idea, but a far less radical change is needed to get the
> desired result.
> The basic idea is this: it should be possible to use any name as an
> identifier in the syntax, including names
> like 'while' and 'import'. But there is no nee
On Sat, Jul 24, 2010 at 7:08 AM, Guido van Rossum wrote:
>
>
> - Commit privileges: Maybe we've been too careful with only giving
> commit privileges to to experienced and trusted new developers. I
> spoke to Ezio Melotti and from his experience with getting commit
> privileges, it seems to be a c
On Thu, Jul 22, 2010 at 3:26 PM, Nick Coghlan wrote:
> On Fri, Jul 23, 2010 at 12:42 AM, Georg Brandl wrote:
> > Sure -- I don't think this is a showstopper for regex. However if we
> don't
> > include regex in a future version, we might think about increasing
> MAXCACHE
> > a bit, and maybe no
On Tue, Jul 27, 2010 at 6:43 PM, R. David Murray wrote:
> On Tue, 27 Jul 2010 08:27:35 +0200, Stefan Behnel
> wrote:
> > Gregory P. Smith, 27.07.2010 07:40:
> > > A max cache size of 100 was too small. I just increased it to 500 in
> the
> > > py3k branch
On Sun, Oct 31, 2010 at 9:11 AM, Barry Warsaw wrote:
> On Oct 29, 2010, at 08:14 PM, Raymond Hettinger wrote:
>
> >I would like to simplify and clean-up the API for the unittest module
> >by de-documenting assertSetEqual(), assertDictEqual(),
> >assertListEqual, and assertTupleEqual().
>
> As a g
> Didn't you know that you signed in to run arbitrary viruses, worms, and
> trojan horses when you added your machine to the buildbot infrastructure
> :-? You just haven't seen buildbot erasing your hard disk and filling
> your coffee machine with tea, yet.
VMware Server is free. Run buildbots in
On Tue, Jul 25, 2006 at 10:32:13PM -0400, Greg Ward wrote:
>
> what I discovered in the wild the other day was a response like this:
>
> 0005\r\nabcd\n\r\n0004\r\nabc\n\r\n\r\n
>
> i.e. the chunk-size for the terminating empty chunk was missing.
> This cause httplib.py to blow up with ValueErro
Whoever knows how the windows build process works and controls the
python 2.5 windows release builds could you please make sure the
hashlib module gets built + linked with OpenSSL rather than falling
back to its much slower builtin implementations.
http://sourceforge.net/tracker/index.php?func=d
On Mon, Aug 07, 2006 at 03:16:22PM +0200, "Martin v. L?wis" wrote:
> Gregory P. Smith schrieb:
> > Whoever knows how the windows build process works and controls the
> > python 2.5 windows release builds could you please make sure the
> > hashlib module gets built +
On Tue, Aug 08, 2006 at 03:25:46AM +1000, Anthony Baxter wrote:
> I'm nervous about this change being made at this stage of the release
> process.
> It seems to me to have a chance of causing breakages - admittedly a small
> chance, but one that's higher than I'd like.
Sigh. Half the reason I
On Tue, Aug 08, 2006 at 01:46:13AM +0200, "Martin v. L?wis" wrote:
> Gregory P. Smith schrieb:
> > hashlib's OpenSSL implementation on windows comes in the form of a
> > 300k _hashlib.pyd library.
>
> What do you mean by "comes"? I can't
On Tue, Aug 08, 2006 at 02:23:02AM +0200, "Martin v. L?wis" wrote:
> Gregory P. Smith schrieb:
> > Sigh. Half the reason I did the hashlib work was to get much faster
> > optimized versions of the hash algorithms into python. I'll be
> > disappointed if that d
I have supplied a patch that does everything needed to both make the
windows build process build OpenSSL with x86 assembly optimizations on
Win32 and to build the _hashlib.pyd module. It works for me.
The only thing the patch doesn't do is add _hashlib.pyd to the .msi
windows installer because I
On Tue, Aug 08, 2006 at 08:26:08AM +0200, "Martin v. L?wis" wrote:
> Gregory P. Smith schrieb:
> > Widely deployed popular applications use python for both large scale
> > hashing and ssl communications.
>
> Yet, nobody has worried about performance in all t
On Tue, Aug 08, 2006 at 04:54:44PM -0400, Jim Jewett wrote:
> On 8/8/06, "Martin v. L?wis" <[EMAIL PROTECTED]> wrote:
> > Jim Jewett schrieb:
> > > The OpenSSL library implements some algorithms that are patented. The
> > > source code should be fine to (re)distribute, but but there may be a
> > >
> Strictly speaking, it is dropping a feature: a connection that can get
> established with 2.5b3 might not get established with 2.5c1, assuming
> a server that requires some IDEA-based cipher.
>
> > (any sane SSL connection will negotiate AES or 3DES
> > as its cipher; IDEA isn't required)
>
> O
> > It would be instructive to understand how much, if any, python code
> > would break if we lost -0.0. I'm do not believe that there is any
> > reliable way for python code to tell the difference between all of
> > the different types of IEEE 754 zeros and in the special case of -0.0
> >
> I've never liked the "".join([]) idiom for string concatenation; in my
> opinion it violates the principles "Beautiful is better than ugly." and
> "There should be one-- and preferably only one --obvious way to do it.".
> (And perhaps several others.) To that end I've submitted patch #1569040
On Mon, Oct 09, 2006 at 08:11:59PM -0400, Tim Peters wrote:
> [Tim]
> > I just noticed that the bsddb portion of Python fails to compile on
> > the 2.4 Windows buildbots, but for some reason the buildbot machinery
> > doesn't notice the failure:
>
> But it does now. This is the revision that brok
On Fri, Oct 13, 2006 at 06:43:40AM +1000, Anthony Baxter wrote:
> On Friday 13 October 2006 06:25, Barry Warsaw wrote:
> > On Oct 12, 2006, at 3:27 PM, Anthony Baxter wrote:
> > > Mostly it is easy for me, with the one huge caveat. As far as I
> > > know, the Mac
> > > build is a single command to
On Thu, Oct 12, 2006 at 09:30:49PM +0200, Georg Brandl wrote:
> Barry Warsaw wrote:
> > I've offered in the past to dust off my release manager cap and do a
> > 2.3.6 release. Having not done one in a long while, the most
> > daunting part for me is getting the website updated, since I have
On Thu, Oct 12, 2006 at 11:00:09PM +0200, "Martin v. L?wis" wrote:
> Kristj?n V. J?nsson schrieb:
> > This is an improvement of another 3.5 %.
> > In all, we have a performance increase of more than 10%.
> > Granted, this is from a single set of runs, but I think we should start
> > considering to
> I question whether a distro built on Python can even afford to allow
> 3rd party packages to be installed in their system's site-packages.
> Maybe Python needs to extend its system-centric view of site-packages
> with an application-centric and/or user-centric view of extensions?
Agree
On Sun, Dec 03, 2006 at 07:38:21PM +0100, "Martin v. L?wis" wrote:
> Aahz schrieb:
> >>> this one is fairly simple. if `m' is a match object, i'd like to be
> >>> able to write m[1] instead of m.group(1). (similarly, m[:] should return
> >>> the same as list(m.groups()).) this would remove some of
On Wed, Jan 03, 2007 at 02:54:34PM -0500, Barry Warsaw wrote:
> On Jan 3, 2007, at 2:29 PM, Martin v. L?wis wrote:
>
> > Guido van Rossum schrieb:
> >> Maybe this should be done in a more systematic fashion? E.g. by
> >> giving all "internal" header files a "py_" prefix?
> >
> > Yet another alte
On Thu, Jan 04, 2007 at 09:35:16PM -0800, Neal Norwitz wrote:
> I fixed the crash that was due to raising a warning on shutdown. I
> have heard about crashes at shutdown and wonder if this was the cause.
> There might be similar bugs lurking that assume PyModule_GetDict()
> always returns a valid
301 - 400 of 628 matches
Mail list logo
