Ethan Furman writes:
> On 08/11/2014 08:50 PM, Stephen J. Turnbull wrote:
> > Chris Barker - NOAA Federal writes:
> >
> >> It seems pretty pedantic to say: we could make this work well,
> >> but we'd rather chide you for not knowing the "proper" way to do
> >> it.
> >
> > Nobody disagrees.
Hello,
The following commit-ready patches have been waiting for review since
May and earlier.It'd be great if someone could find the time to take a
look. I'll be happy to incorporate feedback as necessary:
* http://bugs.python.org/issue1738 (filecmp.dircmp does exact match
only)
* http://bugs.
On 08/11/2014 08:50 PM, Stephen J. Turnbull wrote:
Chris Barker - NOAA Federal writes:
It seems pretty pedantic to say: we could make this work well,
but we'd rather chide you for not knowing the "proper" way to do
it.
Nobody disagrees. But backward compatibility gets in the way.
Something
Chris Barker - NOAA Federal writes:
> Is there anything in the language spec that says string concatenation is
> O(n^2)? Or for that matter any of the performs characteristics of build in
> types? Those striker as implementation details that SHOULD be particular to
> the implementation.
Conta
Ben Hoyt writes:
> So -- although I'm not arguing for it here -- you'd be turning an code
> (a runtime AttributeError) into valid syntax.
Exactly what I'd want to avoid, especially because it *looks* like a
tuple. There are IMO too many pieces of code that look confusingly
similar to tuples but
Sorry for the bike shedding here, but:
The quadratic behaviour of repeated str summation is a subtle, silent error.
OK, fair enough. I suppose it would be hard and ugly to catch those
instances and raise an exception pointing users to "".join.
*is* controversial that CPython silently optimises s
On Mon, Aug 11, 2014 at 8:19 PM, Nick Coghlan wrote:
> Teaching users the difference between linear time operations and quadratic
> ones isn't about purity, it's about passing along a fundamental principle
> of algorithm scalability.
I would understand if this was done in reduce(operator.add, .
> Even if it weren't a syntax error, the syntax would be ambiguous. How
> will you discern the meaning of::
>
> with (
> foo,
> bar,
> baz):
> pass
>
> Is that three separate context managers? Or is it one tuple with three
> items?
Is it meaningful t
On 12 Aug 2014 09:09, "Allen Li" wrote:
>
> This is a problem I sometimes run into when working with a lot of files
> simultaneously, where I need three or more `with` statements:
>
> with open('foo') as foo:
> with open('bar') as bar:
> with open('baz') as baz:
>
On 12 Aug 2014 03:03, "Chris Barker - NOAA Federal"
wrote:
>
> My confusion is still this:
>
> Repeated summation of strings has been optimized in cpython even
> though it's not the recommended way to solve that problem.
The quadratic behaviour of repeated str summation is a subtle, silent
error.
Allen Li writes:
> Currently, this works with explicit line continuation, but as all
> style guides favor implicit line continuation over explicit, it would
> be nice if you could do the following:
>
> with (open('foo') as foo,
> open('bar') as bar,
> open('baz') as baz,
>
This is a problem I sometimes run into when working with a lot of files
simultaneously, where I need three or more `with` statements:
with open('foo') as foo:
with open('bar') as bar:
with open('baz') as baz:
pass
Thankfully, support for multiple items was
2014-08-11 19:42 GMT+02:00 matsjoyce :
> Yup, I read that post. However, those specific issues do not exist in my
> module, as there is a module whitelist, and a method whitelist. Builtins are
> now proxied, and all types going in to functions are checked for
> modification. There maybe some holes
I see this as a parallel to the question of `pathlib.PurePath.resolve()`, about
which `pathlib` is (rightly!) very opinionated. Just as `foo/../bar` shouldn't
resolve to `bar`, `foo/` shouldn't be truncated to `foo`. And if `PurePath`
doesn't do this, `Path` shouldn't either, because the differe
On 8/11/2014 8:26 AM, Ben Hoyt wrote:
It seems to me this is something of a pointless discussion -- I highly
doubt the current situation is going to change, and it works very well.
Even if not perfect, sum() is for numbers, sep.join() for strings.
However, I will add one comment:
I'm overall
On Mon, Aug 11, 2014 at 12:42 PM, matsjoyce wrote:
> There maybe some holes in my approach, but I can't find them.
There's the rub. Given time, I suspect someone will discover a hole or two.
Skip
___
Python-Dev mailing list
Python-Dev@python.org
https:
On 11/08/2014 18:42, matsjoyce wrote:
Yup, I read that post. However, those specific issues do not exist in my
module, as there is a module whitelist, and a method whitelist. Builtins are
now proxied, and all types going in to functions are checked for
modification. There maybe some holes in my a
Yup, I read that post. However, those specific issues do not exist in my
module, as there is a module whitelist, and a method whitelist. Builtins are
now proxied, and all types going in to functions are checked for
modification. There maybe some holes in my approach, but I can't find them.
On 04.08.2014 22:22, Jim J. Jewett wrote:
>
>
>
> Sat Aug 2 12:11:54 CEST 2014, Julian Taylor wrote (in
> https://mail.python.org/pipermail/python-dev/2014-August/135623.html ) wrote:
>
>
>> Andrea Griffini wrote:
>
>>>However sum([[1,2,3],[4],[],[5,6]], []) concatenates the lists.
>
> I'm very sympathetic to Steven's explanation that "we
> wouldn't be having this discussion if we used a different operator for
> string concatenation".
Sure -- but just imagine the conversations we could be having instead
: what does bit wise and of a string mean? A bytes object? I cod see
it as
> Victor Stinner suggested [1] to allow scandir(fd) but I don't see it
> being mentioned in the pep 471 [2]: it neither supports nor rejects the
> idea.
>
> [1] https://mail.python.org/pipermail/python-dev/2014-July/135283.html
> [2] http://legacy.python.org/dev/peps/pep-0471/
Yes, listdir() suppo
Armin Rigo writes:
> On 10 August 2014 08:11, Larry Hastings wrote:
>>> A small tip from my bzr days - cd into the directory before scanning it
>>
>> I doubt that's permissible for a library function like os.scandir().
>
> Indeed, chdir() is notably not compatible with multithreading. There
> w
"Schmitt Uwe (ID SIS)" writes:
> I discovered a problem using cPickle.loads from CPython 2.7.6.
>
> The last line in the following code raises an infinite recursion
>
> class T(object):
>
> def __init__(self):
> self.item = list()
>
> def __getattr__(self, name):
It seems to me this is something of a pointless discussion -- I highly
doubt the current situation is going to change, and it works very well.
Even if not perfect, sum() is for numbers, sep.join() for strings. However,
I will add one comment:
I'm overall -1 on trying to change the current situatio
Chris Angelico wrote:
> On Mon, Aug 11, 2014 at 9:40 PM, Peter Otten <__pete...@web.de> wrote:
>> Read again. The OP tries to delegate attribute lookup to an (existing)
>> attribute.
>>
>> IMO the root cause of the problem is that pickle looks up __dunder__
>> methods in the instance rather than t
On Mon, 11 Aug 2014 21:43:00 +1000, Chris Angelico wrote:
> On Mon, Aug 11, 2014 at 9:40 PM, Peter Otten <__pete...@web.de> wrote:
> > Read again. The OP tries to delegate attribute lookup to an (existing)
> > attribute.
> >
> > IMO the root cause of the problem is that pickle looks up __dunder__
On Mon, Aug 11, 2014 at 9:40 PM, Peter Otten <__pete...@web.de> wrote:
> Read again. The OP tries to delegate attribute lookup to an (existing)
> attribute.
>
> IMO the root cause of the problem is that pickle looks up __dunder__ methods
> in the instance rather than the class.
The recursion comes
Terry Reedy wrote:
> On 8/11/2014 5:10 AM, Schmitt Uwe (ID SIS) wrote:
>
> Python usage questions should be directed to python-list, for instance.
>
>> I discovered a problem using cPickle.loads from CPython 2.7.6.
>
> The problem is your code having infinite recursion. You only discovered
> it
On 8/11/2014 5:10 AM, Schmitt Uwe (ID SIS) wrote:
Python usage questions should be directed to python-list, for instance.
I discovered a problem using cPickle.loads from CPython 2.7.6.
The problem is your code having infinite recursion. You only discovered
it with pickle.
The last line i
Dear all,
I discovered a problem using cPickle.loads from CPython 2.7.6.
The last line in the following code raises an infinite recursion
class T(object):
def __init__(self):
self.item = list()
def __getattr__(self, name):
return getattr(self.item, n
30 matches
Mail list logo
