On Fri, May 7, 2010 at 21:04, Senthil Kumaran wrote:
> On Sat, May 8, 2010 at 8:19 AM, David Abrahams wrote:
> >
> > This is a bug report. bugs.python.org seems to be down.
>
> Tracked here: http://bugs.python.org/issue8656
>
> > >>> urlunsplit(urlsplit('git+file:///foo/bar/baz'))
>
> Is 'git+
On Sat, May 8, 2010 at 8:19 AM, David Abrahams wrote:
>
> This is a bug report. bugs.python.org seems to be down.
Tracked here: http://bugs.python.org/issue8656
> >>> urlunsplit(urlsplit('git+file:///foo/bar/baz'))
Is 'git+file' a valid protocol? Or was it just your example?
I don't see any r
This is a bug report. bugs.python.org seems to be down.
>>> from urlparse import *
>>> urlunsplit(urlsplit('git+file:///foo/bar/baz'))
git+file:/foo/bar/baz
Note the dropped slashes after the colon.
--
Dave Abrahams Meet me at BoostCon: http://www.boostcon.com
BoostPro Computi
Vincent Davis wrote:
> As a wanabe Dev I think the hardest thing is to find an open issue I can
> actually fix and to have a mentor to help make sure I don't miss
> something I did not know about.
Does the "easy" tag help with that at all? It's intended to mark issues
that aren't delving into dee
A.M. Kuchling wrote:
> On Fri, May 07, 2010 at 07:52:49PM +1000, Nick Coghlan wrote:
>> 3.x). I'll take a stab at a more accurate rationale:
>
> Thanks! I've applied the scalpel and reduced it to:
I saw this go by on the checkin list - looks good (although Philip is
right about mentioning PYTHON
On Thu, May 6, 2010 at 9:29 AM, Antoine Pitrou wrote:
>
> Scanning through open issues will also give you a general idea of what
> kind of functionalities are looking for improvement, or need fixing.
>
> (you can create a new issue and start tackling it yourself, too)
>
> As a wanabe Dev I think
There is obviously interest in your proposal. I suggest you open an
issue on the tracker. Make it a library feature request for 3.2. Upload
the patch as a separate file. I would include the subclass form in the
post to show the intneded effect, for discussion, and also so people can
test and us
On Fri, 7 May 2010, VanL wrote:
I make no effort to look for functional equality between two different
functions. too many side effects could go off trying to make that work,
and it would still be only inconsistently right. (IIRC, doing it
completely is NP-hard.)
Actually, doing it completely
On 5/7/2010 12:41 PM, Steven D'Aprano wrote:
>> Now, if I write
>>
>> def f1(x,y): return x+y
>> def f2(x,y): return x+y
>>
>> I don't expect f1==f2 to be True, even though f1 and f2 behave in
>> exactly the same way, and indeed it is not.
This is not what I am getting after; these (IMO)
A.M. Kuchling wrote:
> On Fri, May 07, 2010 at 09:30:00AM +0200, "Martin v. Löwis" wrote:
>> I agree with Terry: how did you arrive at the 4 years for 2.x releases?
>> Bug fixes releases stopped after the next feature release being made,
>> which gave (counting between initial release and last bug
On May 7, 2010, at 9:09 AM, A.M. Kuchling wrote:
> You can re-enable display of :exc:`DeprecationWarning` messages by
> running Python with the :option:`-Wdefault` (short form:
> :option:`-Wd`) switch, or you can add
> ``warnings.simplefilter('default')`` to your code.
The new PYTHONWARNINGS
On Sat, 8 May 2010 03:57:06 am Steve Holden wrote:
> Steven D'Aprano wrote:
> > On Sat, 8 May 2010 02:07:55 am Rob Cliffe wrote:
> >> Sorry to grouse, but isn't this maybe being a bit too clever?
> >> Using your example,
> >> p1 = partial(operator.add)
> >> is creating a callable, p1, i.e. a so
On Fri, May 7, 2010 at 09:09, A.M. Kuchling wrote:
> On Fri, May 07, 2010 at 07:52:49PM +1000, Nick Coghlan wrote:
> > 3.x). I'll take a stab at a more accurate rationale:
>
> Thanks! I've applied the scalpel and reduced it to:
>
> * A policy decision was made to silence warnings only of interes
On 07/05/2010 19:57, Steve Holden wrote:
Steven D'Aprano wrote:
On Sat, 8 May 2010 02:07:55 am Rob Cliffe wrote:
Sorry to grouse, but isn't this maybe being a bit too clever?
Using your example,
p1 = partial(operator.add)
is creating a callable, p1, i.e. a sort of function. Yes
Steven D'Aprano wrote:
> On Sat, 8 May 2010 02:07:55 am Rob Cliffe wrote:
>> Sorry to grouse, but isn't this maybe being a bit too clever?
>> Using your example,
>> p1 = partial(operator.add)
>> is creating a callable, p1, i.e. a sort of function. Yes I know
>> technically it's not a function,
On Sat, 8 May 2010 02:07:55 am Rob Cliffe wrote:
> Sorry to grouse, but isn't this maybe being a bit too clever?
> Using your example,
> p1 = partial(operator.add)
> is creating a callable, p1, i.e. a sort of function. Yes I know
> technically it's not a function, but it behaves very much like
On Fri, May 7, 2010 at 11:02 AM, Antoine Pitrou wrote:
> VanL gmail.com> writes:
..
>> While I was at it, I also added a nice repr. Would this group be
>> interested in a patch, or is this not interesting?
>
> It would be more useful to provide equality, hashing and repr to partial
> itself,
> r
ACTIVITY SUMMARY (2010-04-30 - 2010-05-07)
Python tracker at http://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue
number. Do NOT respond to this message.
2658 open (+44) / 17807 closed (+24) / 20465 total (+68)
Open issues with patches: 1081
Ave
On Fri, May 07, 2010 at 07:52:49PM +1000, Nick Coghlan wrote:
> 3.x). I'll take a stab at a more accurate rationale:
Thanks! I've applied the scalpel and reduced it to:
* A policy decision was made to silence warnings only of interest to
developers by default. :exc:`DeprecationWarning` and it
Sorry to grouse, but isn't this maybe being a bit too clever?
Using your example,
p1 = partial(operator.add)
is creating a callable, p1, i.e. a sort of function. Yes I know technically
it's not a function, but it behaves very much like one.
Now, if I write
def f1(x,y): return x+y
def
On Fri, May 07, 2010 at 09:30:00AM +0200, "Martin v. Löwis" wrote:
> I agree with Terry: how did you arrive at the 4 years for 2.x releases?
> Bug fixes releases stopped after the next feature release being made,
> which gave (counting between initial release and last bug fix release):
I used the
VanL gmail.com> writes:
>
> I created a subclass of functools.partial that provides appropriate
> __eq__ and __hash__ methods, so that this works as expected. I called
> the subclass a Job:
[...]
>
> While I was at it, I also added a nice repr. Would this group be
> interested in a patch, or is
On 07/05/2010 16:37, VanL wrote:
Howdy all -
I have an app where I am using functools.partial to bundle up jobs to
do, where a job is defined as a callable + args. In one case, I wanted
to keep track of whether I had previously seen a job, so I started
putting them into a set... only to find out
Howdy all -
I have an app where I am using functools.partial to bundle up jobs to
do, where a job is defined as a callable + args. In one case, I wanted
to keep track of whether I had previously seen a job, so I started
putting them into a set... only to find out that partials never test
equal to
Victor Stinner wrote:
> Python 3.0 introduced PyUnicode_DecodeFSDefault() and
> PyUnicode_DecodeFSDefaultAndSize() functions. These functions fallback to
> UTF-8 if getting the file system encoding failed or the encoding is unknown
> (there is not nl_langinfo(CODESET) function).
>
> UTF-8 is no
Le vendredi 07 mai 2010 13:24:18, Antoine Pitrou a écrit :
> > UTF-8 is not a good choice for the fallback because it's incompatible
> > with other encodings like Latin1. I would like to fallback to ASCII on
> > error which is compatible with all encodings (thanks to
> > surrogateescape).
>
> What
Le Fri, 07 May 2010 13:05:52 +0200, Victor Stinner a écrit :
>
> UTF-8 is not a good choice for the fallback because it's incompatible
> with other encodings like Latin1. I would like to fallback to ASCII on
> error which is compatible with all encodings (thanks to
> surrogateescape).
What do you
Python 3.0 introduced PyUnicode_DecodeFSDefault() and
PyUnicode_DecodeFSDefaultAndSize() functions. These functions fallback to
UTF-8 if getting the file system encoding failed or the encoding is unknown
(there is not nl_langinfo(CODESET) function).
UTF-8 is not a good choice for the fallback b
Terry Reedy wrote:
> Then the warnings stuff
>>
>> * Because 2.7 will be running production applications, a policy
>
> Every major version (xcept 3.0) has run production application, and 3.1
> may be and 3.2 certainly will be. So this reasoning is not clear to me.
>
>>decision was made to sil
> * It's very likely the 2.7 release will have a longer period of
> maintenance compared to earlier 2.x versions. Python 2.7 will
> continue to be maintained while the transition to 3.x is in
> progress, and that transition will itself be lengthy. Most 2.x
> versions are maintained for ab
30 matches
Mail list logo
