On Wed, Jun 13, 2012 at 2:30 PM, Stephen J. Turnbull wrote:
> Brett Cannon writes:
> > If anything this new list would act as a showing of good will
>
> "The road to Hell," as they say.
>
> We tried this a couple of times at XEmacs; it didn't work. In
> practice, threads didn't move, they split,
On Wed, Jun 13, 2012 at 11:10 AM, Brett Cannon wrote:
>> > This does mean, though, that imp.cache_from_source() and
>> > imp.source_from_cache() might need to be updated to raise a reasonable
>> > exception when sys.implementation.cache_tag is set to None as I believe
>> > right now it will raise
Brett Cannon writes:
> On Tue, Jun 12, 2012 at 4:09 AM, Stephen J. Turnbull
> wrote:
> > Brett Cannon writes:
> Ah, but you helped make my point!
Not at all; your point has long since been made. I certainly agree
that the current situation is unfortunate. I think it's a bit rude of
you to
On Jun 12, 2012 6:24 PM, "fwierzbi...@gmail.com"
wrote:
>
> On Tue, Jun 12, 2012 at 12:01 PM, Brett Cannon wrote:
> >
> >
> > On Tue, Jun 12, 2012 at 2:28 PM, Eric Snow
> > wrote:
> >>
> >> On Tue, Jun 12, 2012 at 10:48 AM, Brett Cannon
wrote:
> >> > I should mention another option is to add sy
On Tue, 12 Jun 2012 11:23:28 +
Kristján Valur Jónsson wrote:
> Hi,
> Could I get some feedback on this proposed patch?
> It would be great to get it in before the beta.
The review I made on your previous patch still applies.
You shouldn't ask for feedback if you aren't willing to take it into
[Vaguely related:
-B prevents the writing of .pyc and .pyo (don't know how it works for pep 3147)
However, it doesn't prevent the _reading_ of said files. It's been discussed
here before and considered useful, since rudiment .pyc files tend to stick
around. Maybe a -BB flag should be considered
On Tue, Jun 12, 2012 at 12:01 PM, Brett Cannon wrote:
>
>
> On Tue, Jun 12, 2012 at 2:28 PM, Eric Snow
> wrote:
>>
>> On Tue, Jun 12, 2012 at 10:48 AM, Brett Cannon wrote:
>> > I should mention another option is to add sys.dont_read_bytecode (I
>> > think I
>> > have discussed this with Frank at
2012/5/4 Victor Stinner :
> Anyway, the implementation and/or the documentation is buggy and
> should be fixed (especially the Windows case).
Done, I renamed "adjusted" to "adjustable", fixed its value on Windows
(time.time) and Linux (time.monotonic), and updated the doc.
--
changeset: 77415:0e
On Mon, 11 Jun 2012 20:13:53 -0700
"fwierzbi...@gmail.com" wrote:
> On Sun, Jun 10, 2012 at 11:58 PM, Nick Coghlan wrote:
> > 1. Asking on python-dev is considered adequate. If an implementation
> > wants to be consulted on changes, one or more of their developers
> > *must* follow python-dev su
On Tue, Jun 12, 2012 at 3:53 PM, Jeff Hardy wrote:
> On Tue, Jun 12, 2012 at 12:01 PM, Brett Cannon wrote:
> > On Tue, Jun 12, 2012 at 2:28 PM, Eric Snow
> > wrote:
> >>
> >> On Tue, Jun 12, 2012 at 10:48 AM, Brett Cannon
> wrote:
> >> > I should mention another option is to add sys.dont_read_
Le mardi 12 juin 2012 à 11:41 -0700, Ethan Furman a écrit :
> Terry Reedy wrote:
> > http://bugs.python.org/issue12982
> >
> > Currently, cpython requires the -O flag to *read* .pyo files as well as
> > the write them. This is a nuisance to people who receive them from
> > others, without the so
On Tue, Jun 12, 2012 at 12:01 PM, Brett Cannon wrote:
> On Tue, Jun 12, 2012 at 2:28 PM, Eric Snow
> wrote:
>>
>> On Tue, Jun 12, 2012 at 10:48 AM, Brett Cannon wrote:
>> > I should mention another option is to add sys.dont_read_bytecode (I
>> > think I
>> > have discussed this with Frank at som
> 1) imp.cache_from_source is unimplemented, it's an AttributeError.
Same for IronPython.
>
> 2) sys.dont_write_bytecode is always false, we don't respect that flag (we
> really
> should IMO, but it's not a high priority for me, or anyone else apparently)
Always True for IronPython. You can c
I am sorry for mailing it to this list.
Thanks for the correction.
Salman
> Date: Tue, 12 Jun 2012 14:34:04 -0500
> Subject: Re: [Python-Dev] Using pdb with greenlet
> From: br...@python.org
> To: salma...@live.com
> CC: python-dev@python.org
>
> On Tue, Jun 12, 2012 at 2:31 PM, Salman Malik w
Alexandre Zani wrote:
On Tue, Jun 12, 2012 at 11:41 AM, Ethan Furman wrote:
Terry Reedy wrote:
http://bugs.python.org/issue12982
Currently, cpython requires the -O flag to *read* .pyo files as well as
the write them. This is a nuisance to people who receive them from others,
without the sourc
On Tue, Jun 12, 2012 at 2:31 PM, Salman Malik wrote:
> Hi All,
>
> I am sort of a newbie to Python ( have just started to use pdb).
> My problem is that I am debugging an application that uses greenlets and
> when I encounter something in code that spawns the coroutines or wait for an
> event, I l
Hi All,
I am sort of a newbie to Python ( have just started to use pdb).
My problem is that I am debugging an application that uses greenlets and when I
encounter something in code that spawns the coroutines or wait for an event, I
lose control over the application (I mean that after that poin
On Tue, Jun 12, 2012 at 2:28 PM, Eric Snow wrote:
> On Tue, Jun 12, 2012 at 10:48 AM, Brett Cannon wrote:
> > I should mention another option is to add sys.dont_read_bytecode (I
> think I
> > have discussed this with Frank at some point).
>
> Or check for "sys.implementation.cache_tag is None"...
On Tue, Jun 12, 2012 at 11:41 AM, Ethan Furman wrote:
> Terry Reedy wrote:
>>
>> http://bugs.python.org/issue12982
>>
>> Currently, cpython requires the -O flag to *read* .pyo files as well as
>> the write them. This is a nuisance to people who receive them from others,
>> without the source. The
Terry Reedy wrote:
http://bugs.python.org/issue12982
Currently, cpython requires the -O flag to *read* .pyo files as well as
the write them. This is a nuisance to people who receive them from
others, without the source. The originator of the issue quotes the
following from the doc (without gi
On Tue, Jun 12, 2012 at 10:48 AM, Brett Cannon wrote:
> I should mention another option is to add sys.dont_read_bytecode (I think I
> have discussed this with Frank at some point).
Or check for "sys.implementation.cache_tag is None"...
-eric
___
Python
http://bugs.python.org/issue12982
Currently, cpython requires the -O flag to *read* .pyo files as well as
the write them. This is a nuisance to people who receive them from
others, without the source. The originator of the issue quotes the
following from the doc (without giving the location).
On 6/12/2012 9:40 AM, Alon Horev wrote:
Hi All,
First of all, I'm not opening a bug yet as I'm not certain whether this
is a CPython bug or lxml bug.
lxml is more likely, making this a topic for python-list and whatever
lxml list.
...
from lxml.etree import iterparse
...
anyone familiar
On Tue, Jun 12, 2012 at 1:04 PM, fwierzbi...@gmail.com <
fwierzbi...@gmail.com> wrote:
> On Tue, Jun 12, 2012 at 9:38 AM, Alex Gaynor
> wrote:
> > For PyPy: I'm not an expert in our import, but from looking at the source
> >
> > 1) imp.cache_from_source is unimplemented, it's an AttributeError.
>
On Tue, Jun 12, 2012 at 10:04 AM, fwierzbi...@gmail.com
wrote:
> Jython does support sys.dont_write_bytecode, but doesn't support
> sys.dont_read_bytecode yet - do you happen to know when
> dont_read_bytecode was added? It should be pretty straightforward, and
> so I'll probably add it to our 2.7.
On Tue, Jun 12, 2012 at 9:38 AM, Alex Gaynor wrote:
> For PyPy: I'm not an expert in our import, but from looking at the source
>
> 1) imp.cache_from_source is unimplemented, it's an AttributeError.
Jython does not (yet) have a cache_from_source.
> 2) sys.dont_write_bytecode is always false, we d
2012/6/12 Alex Gaynor
>
>
> On Tue, Jun 12, 2012 at 11:47 AM, Brett Cannon wrote:
>
>>
>>
>> On Tue, Jun 12, 2012 at 12:38 PM, Alex Gaynor wrote:
>>
>>> For PyPy: I'm not an expert in our import, but from looking at the source
>>>
>>> 1) imp.cache_from_source is unimplemented, it's an AttributeE
On Tue, Jun 12, 2012 at 11:47 AM, Brett Cannon wrote:
>
>
> On Tue, Jun 12, 2012 at 12:38 PM, Alex Gaynor wrote:
>
>> For PyPy: I'm not an expert in our import, but from looking at the source
>>
>> 1) imp.cache_from_source is unimplemented, it's an AttributeError.
>>
>
> Well, you will have it co
On Tue, Jun 12, 2012 at 10:52 AM, Brett Cannon wrote:
> I would like to have importlib just work out of the box for all VMs in 3.3
> instead of requiring a minor patch in order to not throw an exception when
> loading from source and there is no bytecode. The relevant code for this
> discussion c
On Tue, Jun 12, 2012 at 12:38 PM, Alex Gaynor wrote:
> For PyPy: I'm not an expert in our import, but from looking at the source
>
> 1) imp.cache_from_source is unimplemented, it's an AttributeError.
>
Well, you will have it come Python 3.3 one way or another. =)
>
> 2) sys.dont_write_bytecode
On Tue, Jun 12, 2012 at 10:59 AM, Mark Lawrence wrote:
> On 12/06/2012 15:40, Brett Cannon wrote:
>
>>
>> Ah, but you helped make my point! For the people working on CPython,
>> python-dev is a natural place. But what about PyPy, IronPython, or Jython
>> (toss in Cython or any future VMs and it ju
For PyPy: I'm not an expert in our import, but from looking at the source
1) imp.cache_from_source is unimplemented, it's an AttributeError.
2) sys.dont_write_bytecode is always false, we don't respect that flag (we
really
should IMO, but it's not a high priority for me, or anyone else appare
On 12/06/2012 15:40, Brett Cannon wrote:
Ah, but you helped make my point! For the people working on CPython,
python-dev is a natural place. But what about PyPy, IronPython, or Jython
(toss in Cython or any future VMs and it just became an even larger spread
of teams)? Do they naturally think to
On Mon, Jun 11, 2012 at 11:37 PM, Nick Coghlan wrote:
> On Tue, Jun 12, 2012 at 1:17 PM, Albert Zeyer
> wrote:
> > I also searched a bit around and I didn't directly found any easier
> > way to do this. Only a post from 2009
> > (http://mail.python.org/pipermail/cplusplus-sig/2009-January/014178
I would like to have importlib just work out of the box for all VMs in 3.3
instead of requiring a minor patch in order to not throw an exception when
loading from source and there is no bytecode. The relevant code for this
discussion can be seen at
http://hg.python.org/cpython/file/c2910971eb86/Lib
On Tue, Jun 12, 2012 at 9:49 AM, fwierzbi...@gmail.com <
fwierzbi...@gmail.com> wrote:
> On Mon, Jun 11, 2012 at 10:46 PM, Nick Coghlan wrote:
> > To allow easier transition to a separate list (if that seems necessary
> > at a later date), my preferred colour for the bikeshed is
> > [compatibilit
On Tue, Jun 12, 2012 at 4:09 AM, Stephen J. Turnbull wrote:
> Brett Cannon writes:
>
> > Not necessarily. Just like discussions on SIGs can start and end
> > there, I see no requirement that discussions on the list end up on
> > python-dev.
>
> You've missed my point, which is that for many peo
On Mon, Jun 11, 2012 at 10:46 PM, Nick Coghlan wrote:
> To allow easier transition to a separate list (if that seems necessary
> at a later date), my preferred colour for the bikeshed is
> [compatibility-sig].
I for one approve of this bikeshed colour :)
-Frank
___
Hi All,
First of all, I'm not opening a bug yet as I'm not certain whether this is
a CPython bug or lxml bug.
I'm getting a segfault within python's GC (garbage collector) module.
here's the stack trace:
#0 0x7fc7e9f6b76e in gc_list_remove (op=0x7fc79cef3d98) at
Modules/gcmodule.c:211
#1 P
Hi,
Could I get some feedback on this proposed patch? It would be great to get it
in before the beta.
Cheers,
Kristján
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python
On Mon, Jun 11, 2012 at 8:58 AM, Nick Coghlan wrote:
> On Mon, Jun 11, 2012 at 11:29 AM, Guido van Rossum
> wrote:
> > But what guarantee do you have that (a) the right people sign up for
> > the new list, and (b) topics are correctly brought up there instead of
> > on python-dev? I agree that p
Brett Cannon writes:
> Not necessarily. Just like discussions on SIGs can start and end
> there, I see no requirement that discussions on the list end up on
> python-dev.
You've missed my point, which is that for many people working on
CPython, python-dev will be the natural place to discuss t
42 matches
Mail list logo
