It's actually an ImportWarning, not Error (or at least that's what I meant
on import-sig). If the module is eventually found then there is no error.
On Thu, Apr 19, 2012 at 18:56, eric.smith wrote:
> http://hg.python.org/peps/rev/af61fe9a56fb
> changeset: 4281:af61fe9a56fb
> user:Eric V
If you have any comments, please join the discussion over in import-sig.
Eric.
___
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/archive%40
On Thu, Apr 19, 2012 at 17:21, Stefan Behnel wrote:
> Brian Curtin, 19.04.2012 23:19:
>> On Thu, Apr 19, 2012 at 16:08, Stefan Behnel
While code generation alleviates the burden of tedious languages, it's also
infinitely more complex, makes debugging very difficult and adds to
prere
Brian Curtin, 19.04.2012 23:19:
> On Thu, Apr 19, 2012 at 16:08, Stefan Behnel
>>> While code generation alleviates the burden of tedious languages, it's also
>>> infinitely more complex, makes debugging very difficult and adds to
>>> prerequisite knowledge, among other drawbacks.
>>
>> You can use
On 19Apr2012 10:47, Stephen J. Turnbull wrote:
| On Thu, Apr 19, 2012 at 8:15 AM, Victor Stinner
| wrote:
| > Well, I asked on IRC what I should do for these definitions because
| > I'm too tired to decide what to do. [[...]] I replaced these definitions
with yours.
|
| That was nice of you. I
On Thu, Apr 19, 2012 at 16:08, Stefan Behnel
>> While code generation alleviates the burden of tedious languages, it's also
>> infinitely more complex, makes debugging very difficult and adds to
>> prerequisite knowledge, among other drawbacks.
>
> You can use gdb for source level debugging of Cyth
> PEP: 419
> Title: Protecting cleanup statements from interruptions
> Version: $Revision$
> Last-Modified: $Date$
> Author: Paul Colomiets
> Status: Draft
> Type: Standards Track
> Content-Type: text/x-rst
> Created: 06-Apr-2012
> Python-Version: 3.3
Hi, I think your PEP should at least mention
Matt Joiner, 19.04.2012 16:13:
> Personally I find the unholy product of C and Python that is Cython to be
> more complex than the sum of the complexities of its parts. Is it really
> wise to be learning Cython without already knowing C, Python, and the
> CPython object model?
The main obstacle th
On Thu, Apr 19, 2012 at 10:30 AM, Antoine Pitrou wrote:
> On Thu, 19 Apr 2012 10:21:00 -0700
> Guido van Rossum wrote:
>> On Thu, Apr 19, 2012 at 10:13 AM, Tshepang Lekhonkhobe
>> wrote:
>> > On Thu, Apr 19, 2012 at 18:55, Guido van Rossum wrote:
>> >> On Thu, Apr 19, 2012 at 9:02 AM, Tshepang
Le jeudi 19 avril 2012 à 10:40 -0700, Guido van Rossum a écrit :
> >>
> >> I don't think you're a core contributor, right? Even if a core
> >> developer reviews the code, it requires a certain level of trust,
> >> especially for complex patches.
> >
> > I would say trust is gained through previous
On Thu, 19 Apr 2012 10:21:00 -0700
Guido van Rossum wrote:
> On Thu, Apr 19, 2012 at 10:13 AM, Tshepang Lekhonkhobe
> wrote:
> > On Thu, Apr 19, 2012 at 18:55, Guido van Rossum wrote:
> >> On Thu, Apr 19, 2012 at 9:02 AM, Tshepang Lekhonkhobe
> >> wrote:
> >>> On Thu, Apr 19, 2012 at 17:51, Gui
On Thu, Apr 19, 2012 at 10:13 AM, Tshepang Lekhonkhobe
wrote:
> On Thu, Apr 19, 2012 at 18:55, Guido van Rossum wrote:
>> On Thu, Apr 19, 2012 at 9:02 AM, Tshepang Lekhonkhobe
>> wrote:
>>> On Thu, Apr 19, 2012 at 17:51, Guido van Rossum wrote:
and I'm not sure we'd like to
accept cod
On Thu, Apr 19, 2012 at 18:55, Guido van Rossum wrote:
> On Thu, Apr 19, 2012 at 9:02 AM, Tshepang Lekhonkhobe
> wrote:
>> On Thu, Apr 19, 2012 at 17:51, Guido van Rossum wrote:
>>> and I'm not sure we'd like to
>>> accept code from convicted fellons (though I'd consider that a gray
>>> area).
>
On Thu, Apr 19, 2012 at 9:06 AM, Glyph wrote:
> On Apr 19, 2012, at 11:51 AM, Guido van Rossum wrote:
>
> In all those cases I think there should be some core contributors who
> know the real identity of the contributor. These must also know the
> reason for the anonymity and agree that it's impor
On Thu, Apr 19, 2012 at 9:02 AM, Tshepang Lekhonkhobe
wrote:
> On Thu, Apr 19, 2012 at 17:51, Guido van Rossum wrote:
>> and I'm not sure we'd like to
>> accept code from convicted fellons (though I'd consider that a gray
>> area).
>
> This makes me curious... why would that be a problem at all (
On Apr 19, 2012, at 11:51 AM, Guido van Rossum wrote:
> In all those cases I think there should be some core contributors who
> know the real identity of the contributor. These must also know the
> reason for the anonymity and agree that it's important to maintain it.
> It must also be known to th
On Thu, Apr 19, 2012 at 17:51, Guido van Rossum wrote:
> and I'm not sure we'd like to
> accept code from convicted fellons (though I'd consider that a gray
> area).
This makes me curious... why would that be a problem at all (assuming
the felony is not related to the computing field)?
__
On Thu, Apr 19, 2012 at 4:19 AM, "Martin v. Löwis" wrote:
Issue #11750: The Windows API functions scattered in the _subprocess and
_multiprocessing.win32 modules now live in a single module "_winapi".
Patch by sbt.
>>>
>>> Can we use Real Names, please?
>>
>> Do we have a policy a
was sent to Barry-only by mistake
On Thu, Apr 19, 2012 at 17:20, Tshepang Lekhonkhobe wrote:
> On Thu, Apr 19, 2012 at 17:15, Barry Warsaw wrote:
>> If I change that phrase to "Use your own judgement" does that help?
>
> I would prefer "This is a matter of taste...". Much closer to original
> me
If I change that phrase to "Use your own judgement" does that help?
It does. It may also help fight the mindset that PEP 8 is a Law.
Regards
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscr
On Thu, Apr 19, 2012 at 11:15:38AM -0400, Barry Warsaw wrote:
> On Apr 19, 2012, at 11:00 AM, ??ric Araujo wrote:
> >> +- If operators with different priorities are used, consider adding
> >> + whitespace around the operators with the lowest priority(ies). This
> >> + is very much to taste; howe
On Apr 19, 2012, at 11:00 AM, Éric Araujo wrote:
>Hi,
>
>> +- If operators with different priorities are used, consider adding
>> + whitespace around the operators with the lowest priority(ies). This
>> + is very much to taste; however, never use more than one space, and
>> + always have the sa
On Fri, Apr 20, 2012 at 1:00 AM, Éric Araujo wrote:
> Hi,
>
>> +- If operators with different priorities are used, consider adding
>> + whitespace around the operators with the lowest priority(ies). This
>> + is very much to taste; however, never use more than one space, and
>> + always have th
Hi,
+- If operators with different priorities are used, consider adding
+ whitespace around the operators with the lowest priority(ies). This
+ is very much to taste; however, never use more than one space, and
+ always have the same amount of whitespace on both sides of a binary
+ operator.
On Apr 18, 2012, at 09:26 PM, Guido van Rossum wrote:
>On Wed, Apr 18, 2012 at 8:14 PM, Chris Angelico wrote:
>> On Thu, Apr 19, 2012 at 1:06 PM, Eli Bendersky wrote:
>>> (quoting GvR)
Let's change this to something more reasonable, e.g.
"""
If operators with different priori
Personally I find the unholy product of C and Python that is Cython to be
more complex than the sum of the complexities of its parts. Is it really
wise to be learning Cython without already knowing C, Python, and the
CPython object model?
While code generation alleviates the burden of tedious lang
On Thu, 19 Apr 2012 14:44:06 +0200, Antoine Pitrou wrote:
> Also, while C is a low-level language, Cython is a different language
> than Python when you start using its optimization features. This means
> core developers have to learn that language.
Hmm. On the other hand, perhaps some core deve
On Thu, Apr 19, 2012 at 05:38, Nick Coghlan wrote:
> On Thu, Apr 19, 2012 at 6:55 PM, Stefan Behnel wrote:
>> What do you think?
>
> I think the possible use of Cython for standard library extension
> modules is potentially worth looking into for the 3.4 timeframe (c.f.
> the recent multiple chec
On Thu, 19 Apr 2012 10:55:24 +0200
Stefan Behnel wrote:
>
> I noticed that there is a PEP (3154) and a GSoC proposal about improving
> Pickle. Given the recent discussion on this list about using Cython for the
> import module, I wonder if it wouldn't make even more sense to switch from
> a C (ac
>>> Issue #11750: The Windows API functions scattered in the _subprocess and
>>> _multiprocessing.win32 modules now live in a single module "_winapi".
>>> Patch by sbt.
>>
>> Can we use Real Names, please?
>
> Do we have a policy about that? sbt seems happy using a pseudonym (and
> I personally
Am 19.04.2012 12:42, schrieb Sam Partington:
> On 19 April 2012 02:20, Nick Coghlan wrote:
>> On Thu, Apr 19, 2012 at 12:21 AM, Antoine Pitrou wrote:
>>> (and here we see why reference-stealing APIs are a nuisance: because
>>> you never know in advance whether a function will steal a reference or
On 19 April 2012 02:20, Nick Coghlan wrote:
> On Thu, Apr 19, 2012 at 12:21 AM, Antoine Pitrou wrote:
>> (and here we see why reference-stealing APIs are a nuisance: because
>> you never know in advance whether a function will steal a reference or
>> not, and you have to read the docs for each an
On Thu, Apr 19, 2012 at 6:55 PM, Stefan Behnel wrote:
> What do you think?
I think the possible use of Cython for standard library extension
modules is potentially worth looking into for the 3.4 timeframe (c.f.
the recent multiple checkins sorting out the refcounts for the new
ImportError helper
> What do you think?
I think I know what Jim Fulton thinks (as we talked about something
like this a PyCon): don't. He is already sad that cPickle grew so much
pickle features when it was designed as a real fast implementation.
pickle speed is really important to some users, and any loss of
perfor
Am 19.04.2012 10:00, schrieb Eric Snow:
> How closely is tokenize.detect_encoding() supposed to match
> PyTokenizer_FindEncoding()? From what I can tell, there is a subtle
> difference in their behavior that has bearing on PEP 263 handling
> during import. [1] Should any difference be considered
Hi,
I noticed that there is a PEP (3154) and a GSoC proposal about improving
Pickle. Given the recent discussion on this list about using Cython for the
import module, I wonder if it wouldn't make even more sense to switch from
a C (accelerator) implementation to Cython for _pickle.
The rationale
Forgot the subject (going to bed now).
On Thu, Apr 19, 2012 at 2:00 AM, Eric Snow wrote:
> How closely is tokenize.detect_encoding() supposed to match
> PyTokenizer_FindEncoding()? From what I can tell, there is a subtle
> difference in their behavior that has bearing on PEP 263 handling
> durin
How closely is tokenize.detect_encoding() supposed to match
PyTokenizer_FindEncoding()? From what I can tell, there is a subtle
difference in their behavior that has bearing on PEP 263 handling
during import. [1] Should any difference be considered a bug, or
should I work around it? Thanks.
-er
38 matches
Mail list logo
