On 08/11/2012 20:43, Georg Brandl wrote:
On 11/06/2012 02:56 PM, tim.golden wrote:
http://hg.python.org/cpython/rev/dafca4714298
changeset: 80273:dafca4714298
user:Tim Golden
date:Tue Nov 06 13:50:42 2012 +
summary:
issue9584: Add {} list expansion to glob. Original pat
On 11/08/2012 09:43 PM, Georg Brandl wrote:
>
> Needs a versionchanged.
>
> In any case, brace expansion is not part of globbing (see the bash or zsh
> manuals) because it does not generate valid file names, and it is a non-POSIX
> expansion of some shells. Are you sure it should be put into the
On 11/06/2012 02:56 PM, tim.golden wrote:
> http://hg.python.org/cpython/rev/dafca4714298
> changeset: 80273:dafca4714298
> user:Tim Golden
> date:Tue Nov 06 13:50:42 2012 +
> summary:
> issue9584: Add {} list expansion to glob. Original patch by Mathieu Bridon
>
> files:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/08/2012 02:51 PM, Tres Seaver wrote:
> On 11/08/2012 12:59 PM, Guido van Rossum wrote:
>> In Python, you can write
>
>> if C.__eq__ == object.__eq__: print('class C does not override
>> __eq__')
>
>> Does that help?
>
> That works in Python3,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/08/2012 12:59 PM, Guido van Rossum wrote:
> In Python, you can write
>
> if C.__eq__ == object.__eq__: print('class C does not override
> __eq__')
>
> Does that help?
That works in Python3, but not in Python2 -- methodwrappers don't compare
eq
On 08.11.12 20:10, Alexandre Vassalotti wrote:
So should we change the test back? Or just change the test name?
No. I also missed some details. The issue is still not closed.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/ma
On Thu, Nov 8, 2012 at 9:45 AM, Serhiy Storchaka wrote:
> My intention was testing with filename which cannot be decoded as UTF-8 in
> strict mode. I agree that testing with name which is encodable in locale
> encoding can be useful too, but now the test has no effect on UTF-8 locale.
So should
On 08.11.12 03:11, Ned Batchelder wrote:
> Sorry, I should have been clearer: I was asking about weird not to say,
> "This is weird and should be changed!", but to get clarification from
> Serhiy about his statement, " It will be weird if a dict comprehension
> and a plain loop will be inconsist
In Python, you can write
if C.__eq__ == object.__eq__:
print('class C does not override __eq__')
Does that help?
On Thu, Nov 8, 2012 at 9:55 AM, Tres Seaver wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 11/08/2012 12:38 PM, Guido van Rossum wrote:
>> Well, the default beha
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/08/2012 12:38 PM, Guido van Rossum wrote:
> Well, the default behavior has changed to raise an exception when
> using <, <=, >, >=; i.e., inequalities do not have a default
> implementation at all. Perhaps that is enough for your purpose? ==
>
On 08.11.12 01:08, R. David Murray wrote:
Alexandre's point was that the string did not appear to be arbitrary,
but rather appeared to specifically be a string containing surrogates.
Is this not the case?
My intention was testing with filename which cannot be decoded as UTF-8
in strict mode.
Well, the default behavior has changed to raise an exception when
using <, <=, >, >=; i.e., inequalities do not have a default
implementation at all. Perhaps that is enough for your purpose? == and
!= still compare by pointer, but you're primarily interested in
ordering her, right?
On Thu, Nov 8,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
While porting the BTrees package (split out from ZODB) to Python3., my
first step is to get the pure-Python reference implementation working:
in order to do that, I need a way to check that objects used as keys are
*not* using the comparison semantics
On Fri, Nov 9, 2012 at 12:32 AM, Stefan Behnel wrote:
> here's an updated proposal, adopting Marc-Andre's improvement that uses a
> new field in the PyModuleDef struct to register the callback. Note that
> this change no longer keeps up binary compatibility, which may or may not
> be acceptable f
Brett Cannon, 08.11.2012 16:06:
> On Thu, Nov 8, 2012 at 10:00 AM, Stefan Behnel wrote:
>
>> Hi Brett,
>>
>> thanks for the feedback.
>>
>> Brett Cannon, 08.11.2012 15:41:
>>> On Thu, Nov 8, 2012 at 7:47 AM, Stefan Behnel wrote:
I propose to split the extension module initialisation into two
On Thu, Nov 8, 2012 at 10:00 AM, Stefan Behnel wrote:
> Hi Brett,
>
> thanks for the feedback.
>
> Brett Cannon, 08.11.2012 15:41:
> > On Thu, Nov 8, 2012 at 7:47 AM, Stefan Behnel wrote:
> >> I propose to split the extension module initialisation into two steps in
> >> Python 3.4, in a backwards
Hi Brett,
thanks for the feedback.
Brett Cannon, 08.11.2012 15:41:
> On Thu, Nov 8, 2012 at 7:47 AM, Stefan Behnel wrote:
>> I propose to split the extension module initialisation into two steps in
>> Python 3.4, in a backwards compatible way.
>>
>> Step 1: The current module init function can be
On Thu, Nov 8, 2012 at 7:47 AM, Stefan Behnel wrote:
> Hi,
>
> I suspect that this will be put into a proper PEP at some point, but I'd
> like to bring this up for discussion first. This came out of issues 13429
> and 16392.
>
> http://bugs.python.org/issue13429
>
> http://bugs.python.org/issue16
Hi,
here's an updated proposal, adopting Marc-Andre's improvement that uses a
new field in the PyModuleDef struct to register the callback. Note that
this change no longer keeps up binary compatibility, which may or may not
be acceptable for Python 3.4.
Stefan
The problem
===
Python mo
Stefan Behnel, 08.11.2012 14:20:
> M.-A. Lemburg, 08.11.2012 14:01:
>> On 08.11.2012 13:47, Stefan Behnel wrote:
>>> I suspect that this will be put into a proper PEP at some point, but I'd
>>> like to bring this up for discussion first. This came out of issues 13429
>>> and 16392.
>>>
>>> http://b
M.-A. Lemburg, 08.11.2012 14:01:
> On 08.11.2012 13:47, Stefan Behnel wrote:
>> I suspect that this will be put into a proper PEP at some point, but I'd
>> like to bring this up for discussion first. This came out of issues 13429
>> and 16392.
>>
>> http://bugs.python.org/issue13429
>>
>> http://bu
On 08.11.2012 13:47, Stefan Behnel wrote:
> Hi,
>
> I suspect that this will be put into a proper PEP at some point, but I'd
> like to bring this up for discussion first. This came out of issues 13429
> and 16392.
>
> http://bugs.python.org/issue13429
>
> http://bugs.python.org/issue16392
>
> S
Hi,
I suspect that this will be put into a proper PEP at some point, but I'd
like to bring this up for discussion first. This came out of issues 13429
and 16392.
http://bugs.python.org/issue13429
http://bugs.python.org/issue16392
Stefan
The problem
===
Python modules and extension mo
23 matches
Mail list logo
