On Sun, 26 Jan 2014 21:01:08 -0800
Larry Hastings wrote:
> On 01/26/2014 08:40 PM, Alexander Belopolsky wrote:
> >
> > On Sun, Jan 26, 2014 at 11:26 PM, Vajrasky Kok
> > mailto:sky@speaklikeaking.com>> wrote:
> >
> > In case we are taking "not backporting anything at all" road, what is
>
On Mon, 27 Jan 2014 10:45:37 +0100
Victor Stinner wrote:
>
> - Tulip #111: StreamReader.readexactly() now raises an
> IncompleteReadError if the
> end of stream is reached before we received enough bytes, instead of returning
> less bytes than requested.
Why not simply EOFError?
Regards
Antoin
On Mon, 27 Jan 2014 04:01:02 -0800
Larry Hastings wrote:
>
> On 01/27/2014 01:39 AM, Antoine Pitrou wrote:
> > On Sun, 26 Jan 2014 21:01:08 -0800
> > Larry Hastings wrote:
> >> On 01/26/2014 08:40 PM, Alexander Belopolsky wrote:
> >>> On Sun,
On Mon, 27 Jan 2014 20:22:53 +0800
Vajrasky Kok wrote:
>
> >>> from itertools import repeat
> >>> list(repeat('a', 2**31))
> Traceback (most recent call last):
> File "", line 1, in
> MemoryError
Sure, just adjust the number to fit the available memory (here, 2**29
does the trick).
Regards
On Tue, 28 Jan 2014 11:22:40 +0100
Victor Stinner wrote:
> 2014-01-28 "Martin v. Löwis" :
> > Debugging reveals that it is actually the many integer objects which
> > trigger the sharing code. So a much simplified example of Victor's
> > benchmarking code can use
> >
> > data = [0]*1000
> >
>
On Mon, 03 Feb 2014 16:10:03 +
Phil Thompson wrote:
>
> Why is a Latin-1 string considered inconsistent just because it doesn't
> happen to contain any characters in the range 128-255?
Because as Victor said, it allows for some optimization shortcuts (e.g.
a non-ASCII latin1 string cannot b
Hi Victor,
You can find instructions here to produce a patch:
http://docs.python.org/devguide/
The first thing to do would be to create an issue on
http://bugs.python.org/, and post your patch there.
Regards
Antoine.
On Mon, 3 Feb 2014 23:41:22 +0400
Виктор Щерба wrote:
> Hi, guys!
>
> I h
On Mon, 03 Feb 2014 06:43:31 -0800
Larry Hastings wrote:
>
> A: We create a PyMethodDefEx structure with an extra field: "const char
> *signature". We add a new METH_SIGNATURE (maybe just METH_SIG?) flag to
> the flags, indicating that this is an extended structure. When
> iterating over the
On Tue, 04 Feb 2014 02:21:51 -0800
Larry Hastings wrote:
> On 02/04/2014 01:41 AM, Georg Brandl wrote:
> > Clever, but due to the "hidden" space it also increases the frustration
> > factor
> > for people trying to find out "why is this accepted as a signature and not
> > this".
> >
> > I don't
Hello,
Following the previous clinic thread, I realize that the latest
signature improvements actually entail a regression in __doc__.
Compare:
$ ./python -c "print(dict.fromkeys.__doc__)"
Returns a new dict with keys from iterable and values equal to value.
$ python3.3 -c "print(dict.fromkeys.
On Tue, 04 Feb 2014 05:08:28 -0800
Larry Hastings wrote:
> On 02/04/2014 04:17 AM, Antoine Pitrou wrote:
> > As you see the signature string has vanished from the __doc__ contents.
> > This means that any tool directly processing __doc__ attributes to
> > generate (e.g.) au
On Sat, 8 Feb 2014 15:32:23 -0800
Guido van Rossum wrote:
> We could really use more help reviewing and finishing asyncio's docs!
Well, it's probably difficult for people to help when they are not
acquainted with the details of asyncio's functioning :-)
Regards
Antoine.
__
Hello Jessica,
On Thu, 13 Feb 2014 11:08:23 -0500
Jessica McKellar wrote:
> Hi folks,
>
> Terri Oda's original message to this list about CPython's participation in
> Google Summer of Code 2014 is at the end of this email.
>
> If you'd like to see CPython participate in Google Summer of Code 2
On Fri, 14 Feb 2014 10:46:50 +0100
Lennart Regebro wrote:
> >
> > Sending this to python-dev as I'm wondering if this was considered when the
> > choice to have objects of different types raise a TypeError when ordered...
> >
> > So, the concrete I case I have is implementing stable ordering for t
On Fri, 14 Feb 2014 20:13:43 +1000
Nick Coghlan wrote:
> On 14 February 2014 20:02, Antoine Pitrou wrote:
> > On Fri, 14 Feb 2014 10:46:50 +0100
> > Lennart Regebro wrote:
> >> >
> >> > Sending this to python-dev as I'm wondering if this was consi
On Sat, 15 Feb 2014 21:01:36 +0200
Serhiy Storchaka wrote:
> How Enum items should be pickled, by value or by name?
>
> I think that Enum will be used to collect system-depending constants, so
> the value of AddressFamily.AF_UNIX can be 1 on one platform and 2 on
> other. If pickle enums by val
On Sat, 15 Feb 2014 20:12:33 +0200
Serhiy Storchaka wrote:
>
> I wrote a large patch which modifies the tests to use more specific
> methods [1]. Because it is too large, it was divided into many smaller
> patches, and separate issues were opened for them. At the moment the
> major part of the
On Sun, 16 Feb 2014 10:31:21 -0800
Larry Hastings wrote:
>
> Here's how I propose we move forward.
>
> 1) We merge the Derby patch for the builtins module into 3.4, simply
> because it will "demo well".
This still brings potential unstability during the rc phase, so I'd
prefer this patch to wa
On Tue, 18 Feb 2014 10:01:42 -0800
Ethan Furman wrote:
>
> I guess the question is which is more important? Identity comparison or this
> (probably) rare use-case? If we stick
> with identity I'm not aware of any work-around for pickling enum members that
> are aliases on one system, but dis
On Tue, 18 Feb 2014 18:54:23 -0500
Barry Warsaw wrote:
> On Feb 19, 2014, at 12:38 AM, Matthias Klose wrote:
>
> >Am 17.02.2014 00:25, schrieb Larry Hastings:
> >> And my local branch will remain private until 3.4.0 final ships!
> >
> >sorry, but this is so wrong. Is there *any* reason why to kee
On Tue, 18 Feb 2014 18:46:16 -0800
Guido van Rossum wrote:
> I do think there's one legitimate concern -- someone might pull a diff from
> Larry's branch and then accidentally push it back to the public repo, and
> then Larry would be in trouble if he was planning to rebase that diff. (The
> joys
On Tue, 18 Feb 2014 20:03:31 -0800
Larry Hastings wrote:
>
> Only thirty cherry-picked revisions so far. Gosh, you're making my life
> easy, guys,
That's a large number of cherry-picked revisions. How many are actually
release-critical?
Regards
Antoine.
On Thu, 20 Feb 2014 10:24:16 +0900
"Stephen J. Turnbull" wrote:
>
> The argument that a "read-only, no cherrypicking by committers" repo
> is nothing but a better tarball is valid, but as I say, AFAICS the
> expected gain is pretty marginal. The conflict here is not Larry's
> process, it's the d
On Wed, 19 Feb 2014 19:20:12 -0800
Larry Hastings wrote:
>
> As for a "user beware" clone: I worry about providing anything that
> looks/tastes/smells like a repo. Someone could still inadvertently push
> those revisions back to trunk, and then we'd have a real mess on our
> hands.
If you're
On Fri, 21 Feb 2014 00:36:09 -0800
Ethan Furman wrote:
>
> Discussion
> ==
>
> Is there a valid reason to not allow a user to modify how their enums are
> pickled?
>
> If not, should we put the change in RC2 / Final? The main reason I'm pushing
> for this is that Enum is still new, b
On Fri, 21 Feb 2014 02:06:07 -0800
Larry Hastings wrote:
>
> Whoopsie! My local branch is actually correct. But! I effectively did
> this in my automation:
>
> % hg clone 3.4 python-{time}
> % cd python-{time}
> % rm -rf .hg* .bzr* .git*
> % cd ..
> % tar cvfz python-{tim
On Fri, 21 Feb 2014 14:15:59 +1100
Chris Angelico wrote:
>
> A number of functions and methods have parameters which will cause
> them to return a specified value instead of raising an exception. The
> current system is ad-hoc and inconsistent, and requires that each
> function be individually w
On Sat, 22 Feb 2014 00:28:01 +1000
Nick Coghlan wrote:
>
> Neither of these objections addresses the problems with the status quo,
> though:
>
> - the status quo encourages overbroad exception handling (as
> illustrated by examples in the PEP)
I don't get this. Using the proper exception class
On Sat, 22 Feb 2014 02:12:04 +1100
Chris Angelico wrote:
>
> Overbroad exception handling comes in two ways. One is simply catching
> Exception or BaseException when a narrower class would be better, and
> that's not addressed by this PEP (except insofar as it does not have a
> bare "except:" syn
On Sat, 22 Feb 2014 02:52:59 +1100
Chris Angelico wrote:
> On Sat, Feb 22, 2014 at 1:34 AM, Brett Cannon wrote:
> > While I like the general concept, I agree that it looks too much like a
> > crunched statement; the use of the colon is a non-starter for me. I'm sure
> > I'm not the only one whos
On Sat, 22 Feb 2014 15:57:02 +0900
"Stephen J. Turnbull" wrote:
>
> try:
> interpolable = func(key)
> except TypeError:
> interpolable = "not a string: %s" % key
> except KeyError:
> interpolable = "no such key: %s" % key
> print("Some message that refers t
On Fri, 21 Feb 2014 09:37:29 -0800
Guido van Rossum wrote:
> I'm put off by the ':' syntax myself (it looks to me as if someone forgot a
> newline somewhere) but 'then' feels even weirder (it's been hard-coded in
> my brain as meaning the first branch of an 'if').
Would 'else' work rather than 't
On Sat, 22 Feb 2014 16:12:27 +0900
"Stephen J. Turnbull" wrote:
>
> Note in support: I originally thought that "get" methods would be more
> efficient, but since Nick pointed out that "haveattr" is implemented
> by catching the exception (Yikes! LBYL implemented by using EAFP!), I
> assume that g
On Fri, 21 Feb 2014 19:49:20 -0700
Eric Snow wrote:
> On Fri, Feb 21, 2014 at 7:07 PM, Victor Stinner
> wrote:
> >> Consider this example of a two-level cache::
> >> for key in sequence:
> >> x = (lvl1[key] except KeyError: (lvl2[key] except KeyError:
> >> f(key)))
> >> # do
On Sat, 22 Feb 2014 01:42:57 -0600
Larry Hastings wrote:
>
> Victor has asked me to cherry-pick 180e4b678003:
>
> http://bugs.python.org/issue20320 (original issue)
> http://hg.python.org/cpython/rev/180e4b678003/ (checkin into trunk)
> http://bugs.python.org/issue20646 (cherry-pi
On Sat, 22 Feb 2014 20:29:27 +1100
Chris Angelico wrote:
>
> Which means that, fundamentally, EAFP is the way to do it. So if PEP
> 463 expressions had existed from the beginning, hasattr() probably
> wouldn't have been written - people would just use an
> except-expression instead.
Really? hasa
On Sat, 22 Feb 2014 21:09:07 +1100
Chris Angelico wrote:
> On Sat, Feb 22, 2014 at 8:58 PM, Antoine Pitrou wrote:
> > On Sat, 22 Feb 2014 20:29:27 +1100
> > Chris Angelico wrote:
> >>
> >> Which means that, fundamentally, EAFP is the way to do it. So if PEP
>
On sam., 2014-02-22 at 19:29 +0900, Stephen J. Turnbull wrote:
> Antoine Pitrou writes:
>
> > Well, the only way to know that a key (or attribute) exists is to do
> > the lookup. What else would you suggest?
>
> Do the lookup at the C level (or whatever the implement
On Sat, 22 Feb 2014 22:13:58 +1100
Chris Angelico wrote:
> >
> > Well, can you propose the corresponding except-expression?
>
> It's hard to do hasattr itself without something messy - the best I
> can come up with is this:
>
> hasattr(x,"y") <-> (x.y or True except AttributeError: False)
But i
On sam., 2014-02-22 at 20:54 +0900, Stephen J. Turnbull wrote:
> Antoine Pitrou writes:
> > On sam., 2014-02-22 at 19:29 +0900, Stephen J. Turnbull wrote:
> > > Antoine Pitrou writes:
> > >
> > > > Well, the only way to know that a key (or attribut
On Sat, 22 Feb 2014 20:48:04 -0800
Ethan Furman wrote:
> On 02/22/2014 07:47 PM, Cameron Simpson wrote:
> > On 22Feb2014 17:56, Ethan Furman wrote:
> >> Please let me know if anything else needs tweaking.
> >> [...]
> >> This area of programming is characterized by a mixture of binary data and
>
On Sat, 22 Feb 2014 17:56:50 -0800
Ethan Furman wrote:
>
> ``%a`` will call :func:``ascii()`` on the interpolated value's
> :func:``repr()``.
> This is intended as a debugging aid, rather than something that should be used
> in production. Non-ascii values will be encoded to either ``\xnn`` or
On Sun, 23 Feb 2014 12:42:59 -0800
Ethan Furman wrote:
> On 02/23/2014 03:33 AM, Antoine Pitrou wrote:
> > On Sat, 22 Feb 2014 17:56:50 -0800
> > Ethan Furman wrote:
> >>
> >> ``%a`` will call :func:``ascii()`` on the interpolated value's
> >&g
On Sun, 23 Feb 2014 14:14:55 -0800
Glenn Linderman wrote:
> On 2/23/2014 1:37 PM, Antoine Pitrou wrote:
> > And you certainly*don't* print debugging output into a wire protocol.
>
> Web server applications do, so they can be displayed in the browser.
They may embed debugg
On Mon, 24 Feb 2014 08:54:08 +1000
Nick Coghlan wrote:
> > > The idea being if we offer %a, folks won't be tempted to abuse
> __bytes__.
> >
> > Which folks are we talking about? This sounds gratuitous.
>
> It's a harm containment tactic, based on the assumption people *will* want
> to include th
On Mon, 24 Feb 2014 09:15:29 -0800
Ethan Furman wrote:
> On 02/23/2014 02:54 PM, Nick Coghlan wrote:
> >
> > It's a harm containment tactic, based on the assumption people *will*
> > want to include the output of ascii() in binary protocols containing
> > ASCII segments, regardless of whether or
On Mon, 24 Feb 2014 09:58:30 -0800
Ethan Furman wrote:
> On 02/24/2014 09:43 AM, Antoine Pitrou wrote:
> > On Mon, 24 Feb 2014 09:15:29 -0800
> > Ethan Furman wrote:
> >> On 02/23/2014 02:54 PM, Nick Coghlan wrote:
> >>>
> >>> It's a harm con
On Mon, 24 Feb 2014 10:40:46 -0800
Ethan Furman wrote:
> Okay, types corrected, most comments taken into account.
>
> %b is right out, %a is still suffering scrutiny.
>
> The arguments seem to boil down to:
>
> We don't need it.
>
> vs
>
> Somebody might, and it's better than having them ina
On Tue, 25 Feb 2014 08:33:53 +1000
Nick Coghlan wrote:
> As far as use cases go, as someone else mentioned, the main one is likely
> to be binary logging and error reporting formats, as it becomes a quick and
> easy way to embed a backslash escaped string.
That's a fringe use case, though. Also,
On Tue, 25 Feb 2014 08:39:40 +0100
Christian Heimes wrote:
>
> this looks pretty serious -- and it caught me off guard, too. :(
>
> https://www.trustedsec.com/february-2014/python-remote-code-execution-socket-recvfrom_into/
>
> Next time please inform the Python Security Response Team about any
Hi Rik,
On Tue, 25 Feb 2014 12:25:27 +0100
Rik wrote:
> I want to try to submit a patch for 2.7, but I don't know how to run the
> tests for the 2.7 branch. `./configure` doesn't seem to create a
> `python.exe` file on the 2.7 branch on OS X Mavericks, and I do need this
> file according to this
On Tue, 25 Feb 2014 08:08:09 -0500
Donald Stufft wrote:
>
> Hash randomization is broken and doesn’t fix anything.
Not sure what you mean with "doesn't fix anything". Hash collisions were
easy to exploit pre-hash randomization, they doesn't seem as easy to
exploit with it.
Regards
Antoine.
_
On Tue, 25 Feb 2014 20:38:46 +0200
Maciej Fijalkowski wrote:
>
> My impression is that a lot of discussion went into hash
> randomization, because it was a high profile issue. It got "fixed",
> then later someone discovered that the fix is completely broken and
> was left at that without much dis
On Wed, 26 Feb 2014 11:40:01 +0200
Serhiy Storchaka wrote:
> There were several suggestions for naming new macros which replace old
> value with new value and then (x)decref old value.
>
> #define Py_XXX(ptr, value)\
> { \
> PyObject *__tmp__ =
On Thu, 27 Feb 2014 17:22:37 + (UTC)
Sturla Molden wrote:
> Brett Cannon wrote:
>
> > The Visual Studio team has publicly stated they will never support C99,
> > so dropping C89 blindly is going to alienate a big part of our user base
> > unless we switch to C++ instead. I'm fine with trying
On Thu, 27 Feb 2014 13:12:24 -0600
Skip Montanaro wrote:
> I think it's at least worthwhile to investigate the use of
> inline/static functions over the current macros. It's been many years
> since I looked at them. I doubt they have gotten any easier to read or
> edit with all their backslashes.
On Thu, 27 Feb 2014 13:27:02 -0600
Skip Montanaro wrote:
> On Thu, Feb 27, 2014 at 1:23 PM, Antoine Pitrou wrote:
> > Well, if we must maintain macros, let's maintain them everywhere and
> > avoid the burden of two different implementations for the same thing.
>
&g
On Sat, 01 Mar 2014 15:08:00 -0500
Terry Reedy wrote:
> On 3/1/2014 2:57 PM, Sebastian Kraft wrote:
> > Hi everybody,
> >
> > more than a year ago I have submitted a patch to enhance the Wave module
> > with read/write support for floating point data.
> >
> > http://bugs.python.org/issue16525
> >
On Sun, 2 Mar 2014 11:11:01 +1100
Chris Angelico wrote:
> More importantly, if there is such an offer, it'd be great to mention
> it somewhere, so people can know what they can do to move an issue
> forward. (And preferably with a link somewhere to what it means to
> review a patch - what it takes
On Sat, 01 Mar 2014 18:04:09 -0500
Terry Reedy wrote:
> >>
> >> Please subscribe to core-mentorship list and post your question there.
> >
> > I don't understand this response. You seem to be assuming that
> > Sebastian is asking for guidance,
>
> I am reading what he posted, which ended with "pl
On Sun, 02 Mar 2014 15:01:01 -0500
Terry Reedy wrote:
> Suppose a 2.7 standard library function is documented as taking a
> 'string' argument, such as these examples from the turtle module.
>
> pencolor(colorstring)
> Set pencolor to colorstring, which is a Tk color specification
> string,
On Tue, 04 Mar 2014 11:16:41 +0100
mar...@v.loewis.de wrote:
>
> Quoting Nick Coghlan :
>
> > If you don't want to do an rc3 despite the cherry picked changes since
> > rc2, then you need to make it easy for people to test the changes
> > directly from the release branch. An opaque intermittently
Le 05/03/2014 03:46, Larry Hastings a écrit :
On 03/04/2014 03:59 PM, Barry Warsaw wrote:
I too would like an rc3, especially to see if issue 19021 can be fixed, which
I suspect will hit a lot of people.
I talked to the other guys on the 3.4 team, and we're all willing to do
an rc3 this weeken
Le 05/03/2014 17:37, Victor Stinner a écrit :
Python 3.4 introduced frame.clear(), but frame.clear() raises an
RuntimeError if the frame is still running. And it doesn't break all
reference cycles.
An obvious workaround is to store the traceback as text, but this
operation is "expensive" especi
Le 05/03/2014 23:53, Nick Coghlan a écrit :
__traceback__ wouldn't change [...]
Uh, really? If you want to suppress all reference cycles, you *have* to
remove __traceback__.
The problem is to make computation of the traceback summary lightweight
enough that it doesn't degrade performance i
Le 06/03/2014 16:03, Yury Selivanov a écrit :
On 2014-03-06, 8:42 AM, Antoine Pitrou wrote:
Le 05/03/2014 23:53, Nick Coghlan a écrit :
__traceback__ wouldn't change [...]
Uh, really? If you want to suppress all reference cycles, you *have*
to remove __traceback__.
The problem is to
On Sat, 8 Mar 2014 11:06:54 +0100
Victor Stinner wrote:
>
> Attached script: never_deleted2.py, it's almost the same but it
> explains better the problem. The script creates MyObject and Future
> objects which are never deleted. Calling gc.collect() does *not* break
> the reference cycle (between
On Sat, 8 Mar 2014 23:16:07 +1000
Nick Coghlan wrote:
> On 8 March 2014 23:01, Victor Stinner wrote:
> > 2014-03-08 12:45 GMT+01:00 Antoine Pitrou :
> >>> Attached script: never_deleted2.py, it's almost the same but it
> >>> explains better the problem.
On Sat, 8 Mar 2014 16:14:23 +0100
Victor Stinner wrote:
> 2014-03-08 14:33 GMT+01:00 Antoine Pitrou :
> > Ok, it's actually quite trivial. The whole chain is kept alive by the
> > "fut" global variable. If you arrange for it to be disposed of:
> >
> >
On Mon, 10 Mar 2014 16:50:12 +0100
Victor Stinner wrote:
> 2014-03-10 16:25 GMT+01:00 Stefan Richthofer :
> > I don't see the point in this discussion.
> > As far as I know, the major version is INTENDED to
> > indicate backward-incompatible changes.
>
> This is not a strict rule. I would like t
On Mon, 10 Mar 2014 17:04:08 +0100
"Stefan Richthofer" wrote:
> > Guido famously hates two digit minor version numbers. :)
>
> This is no problem either. Simply switch to hexadecimal numbering ;)
Or wrap around to negative numbers (a minus sign isn't technically a
digit, is it?).
Regards
Anto
On Mon, 10 Mar 2014 16:08:52 -0700 (PDT)
"Jim J. Jewett" wrote:
> It may also be more common to have multiple __del__ methods in the
> same cycle, if cycles are created by a framework. So the problems
> aren't new, but they may have become considerably more painful.
Multiple __del__s shouldn't c
Le 13/03/2014 11:49, Christian Heimes a écrit :
Thanks a lot David and Victor! The list of security improvements is
missing one, maybe two points that are IMHO relevant:
* All stdlib modules now support server cert verification including
hostname matching and CRL.
CRL? really? I don't remember
Le 13/03/2014 17:18, Serhiy Storchaka a écrit :
13.03.14 17:16, Larry Hastings написав(ла):
I'm strongly considering literally copying over all the content in Doc/
from the default branch to the 3.4 branch. Not cherry-picking doc
changes, simply copying everything en masse. I have two question
On Thu, 13 Mar 2014 14:57:41 +0100
Victor Stinner wrote:
> 2014-03-13 11:49 GMT+01:00 Christian Heimes :
> > * All stdlib modules now support server cert verification including
> > hostname matching and CRL.
> >
> > * http://bugs.python.org/issue16499 isolated mode is a security
> > improvement, t
On Fri, 14 Mar 2014 12:08:22 -0500
Zachary Ware wrote:
> On Fri, Mar 14, 2014 at 10:55 AM, Benjamin Peterson
> wrote:
> > On Fri, Mar 14, 2014, at 08:52 AM, Zachary Ware wrote:
> >> On Fri, Mar 14, 2014 at 10:10 AM, Benjamin Peterson
> >> wrote:
> >> > Why are you readding these when they were
On Fri, 14 Mar 2014 16:25:56 -0400
"R. David Murray" wrote:
> I just want to summarize the status of the modules that
> have been added to the stdlib in 3.4 to make sure they
> are all labeled correctly:
>
> Provisional:
>
> asyncio
> pathlib
These are right.
Regards
Antoine.
__
On Mon, 17 Mar 2014 11:44:28 -0400
Tres Seaver wrote:
>
> Shouldn't we at least do a review of the open issues against 3.3 first,
> particularly those with patches? E.g. "critcal" / "patch review":
>
> http://bugs.python.org/issue?%40search_text=&ignore=file%3Acontent&title=&%40columns=title&id
On Mon, 17 Mar 2014 18:30:53 +0100 (CET)
larry.hastings wrote:
> +(Beta 1 was also "feature freeze"--no new features beyond this point.)
Famous last words :-)
Regards
Antoine.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org
On Mon, 17 Mar 2014 12:57:48 -0700
Sean Felipe Wolfe wrote:
> I'm working on some IDLE oriented bugs and I'm having some trouble
> building the 3.3 branch:
>
> --
> make: *** No rule to make target `Modules/_operator.c', needed by
> `Modules/_operator.o'. Stop.
> --
>
> I did a pull/update, th
On Mon, 17 Mar 2014 13:02:23 -0700
Sean Felipe Wolfe wrote:
> I'm getting my feet wet with the cpython sources and Mercurial. I'm a
> bit confused -- when I checkout a branch, eg. 3.3, and I do an 'hg
> log', why do I see log messages for other branches?
This is a classic hg question, you would g
Hello Xavier,
It is not obvious your message is appropriate for python-dev. It looks
like mere advertising; if it is not, please explain.
To clarify what this mailing-list is about: "On this list the key Python
developers discuss the future of the language and its implementation.
Topics inc
On Tue, 18 Mar 2014 19:21:52 +0100
Christian Heimes wrote:
>
> Sounds like a good deal to me. :) Can the NAO bot do The Silly Walk
> (tm), too? I'm even willing to film and upload movies of NAO vs. my
> cats... :)
I've heard it can mend a buildbot with its own hands.
Regards
Antoine.
_
On Tue, 18 Mar 2014 09:52:05 +0200
Maciej Fijalkowski wrote:
>
> We're thinking about doing an optimization where say:
>
> if x in d:
>return d[x]
>
> where d is a dict would result in only one dict lookup (the second one
> being constant folded away). The question is whether it's ok to do
On Wed, 19 Mar 2014 15:09:04 +0200
Maciej Fijalkowski wrote:
>
> I would like to point out that instructing people does not really
> work. Besides, other examples like this:
>
> if d[x] >= 3:
>d[x] += 1 don't really work.
That's a good point. But then, perhaps PyPy should analyze the __eq__
On Wed, 19 Mar 2014 15:21:16 +0200
Maciej Fijalkowski wrote:
> On Wed, Mar 19, 2014 at 3:17 PM, Antoine Pitrou wrote:
> > On Wed, 19 Mar 2014 15:09:04 +0200
> > Maciej Fijalkowski wrote:
> >>
> >> I would like to point out that instructing people does not
On Wed, 19 Mar 2014 07:09:23 -0700
Thomas Wouters wrote:
>
> He means you're being unrealistically pedantic :) The number of calls to
> __eq__ is _already_ unpredictable, since (as Mark Shannon said) it depends
> among other things on the hashing algorithm and the size of the dict.
Well, I was n
Hello,
It is known to be cumbersome to write a proxy type that will correctly
proxy all special methods (this has to be done manually on the type,
since special methods are not looked up on the instance: a __getattr__
method would not work).
Recently we've had reports of two stdlib types that fo
On Wed, 19 Mar 2014 10:53:31 -0700
Ethan Furman wrote:
> I just made a change to some error messages [1] (really, just one):
>
> old behavior:
>
>'%o' % 3.14
>'float' object cannot be interpreted as an integer
>
> new behavior:
>
>'%o' % 3.14
>%o format: an integer is required
On Wed, 19 Mar 2014 19:32:50 +
Brett Cannon wrote:
> >
> > In http://bugs.python.org/issue19359#msg213530 I proposed to introduce a
> > "proxy
> > protocol" (__proxy__ / tp_proxy) that would be used as a fallback by
> > _PyObject_LookupSpecial to fetch the lookup target, i.e.:
> >
> > def _PyO
On Wed, 19 Mar 2014 20:15:15 +
Paul Moore wrote:
> On 19 March 2014 18:46, Antoine Pitrou wrote:
> > In http://bugs.python.org/issue19359#msg213530 I proposed to introduce a
> > "proxy
> > protocol" (__proxy__ / tp_proxy) that would be used as a fallback by
On Thu, 20 Mar 2014 07:54:39 +1000
Nick Coghlan wrote:
>
> Graeme Dumpleton has also subsequently written a library to handle easier
> creation of correct proxy types: https://pypi.python.org/pypi/wrapt
(is "Graeme" another spelling for "Graham"?)
> It isn't as simple as changing one lookup fun
On Wed, 19 Mar 2014 14:37:42 -0700
Ethan Furman wrote:
> Here's the code in question:
>
> class PsuedoFloat:
> def __init__(self, value):
> self.value = float(value)
> def __int__(self):
> return int(self.value)
>
> pi
On Wed, 19 Mar 2014 15:17:53 -0700
Ethan Furman wrote:
> On 03/19/2014 03:13 PM, Antoine Pitrou wrote:
> > On Wed, 19 Mar 2014 14:37:42 -0700
> > Ethan Furman wrote:
> >> Here's the code in question:
> >>
> >> class PsuedoFlo
Hello,
I've created the 3.4 category in the buildbots setup:
http://buildbot.python.org/all/waterfall?category=3.4.stable
I've also retired 3.2 and 3.3 buildbots. Someone will have to update
the text and URLs at https://www.python.org/dev/buildbot/.
Regards
Antoine.
_
On Sat, 22 Mar 2014 19:07:51 -0400
Donald Stufft wrote:
> As someone who is deeply biased towards improving the packaging tool chain
> and getting people to use it I think that most people will simply use the
> Stdlib even if a more secure alternative exists. Infact one does exist and I
> still
On Sun, 23 Mar 2014 09:08:29 +1000
Nick Coghlan wrote:
> On 23 March 2014 08:53, Ben Darnell wrote:
> > I agree wholeheartedly with the sentiment behind this PEP, but I have
> > concerns about the implementation. If we introduce new APIs into the ssl
> > module then we will see packages and appl
On Sun, 23 Mar 2014 07:11:07 +1000
Nick Coghlan wrote:
>
> It is similar to the previous IDLE policy exception PEP, where we
> decided that cross version consistency of IDLE superseded the general
> policy against backporting enhancements to maintenance branches.
But the consequences are differe
On Sat, 22 Mar 2014 23:54:37 +0100
Thomas Wouters wrote:
>
> Or not rely on the standard library for their security. Much as I realize
> it is necessary for rudimentary SSL support (for example) to exist in the
> standard library,
Unfortunately, "rudimentary SSL support" is worse than nothing.
On Sun, 23 Mar 2014 10:59:22 +1100
Chris Angelico wrote:
>
> Is it really that bad to have something depend on "2.7.10" rather than
> "2.7.0"?
It makes our whole release and versioning scheme very confusing
(hopefully people will not have to read Nick's PEP to understand
it :-)).
Regards
Antoi
701 - 800 of 4909 matches
Mail list logo
