Am 26.09.2013 08:22, schrieb Nick Coghlan:
> On 26 September 2013 15:42, Armin Rigo wrote:
>> Hi Nick,
>>
>> On Thu, Sep 26, 2013 at 6:59 AM, Nick Coghlan wrote:
I'm strongly in favour of Georg's one ("Exception in __del__ caught and
not propagated").
>>>
>>> Such a change is highly un
On Wed, 25 Sep 2013 19:15:05 -0400
Barry Warsaw wrote:
> On Sep 25, 2013, at 07:08 PM, Donald Stufft wrote:
>
> >On Sep 25, 2013, at 7:04 PM, Barry Warsaw wrote:
> >
> >> So, why shouldn't we add enum to the Python 2.7 stdlib?
>
> >Because with PEP453 you can just ``pip install enum34`` it :)
>
On 26 September 2013 15:42, Armin Rigo wrote:
> Hi Nick,
>
> On Thu, Sep 26, 2013 at 6:59 AM, Nick Coghlan wrote:
>>> I'm strongly in favour of Georg's one ("Exception in __del__ caught and not
>>> propagated").
>>
>> Such a change is highly unlikely to happen, as it would require
>> changing ev
Hi Nick,
On Thu, Sep 26, 2013 at 6:59 AM, Nick Coghlan wrote:
>> I'm strongly in favour of Georg's one ("Exception in __del__ caught and not
>> propagated").
>
> Such a change is highly unlikely to happen, as it would require
> changing every location where we call PyErr_WriteUnraisable.
Er, wh
On 26 September 2013 14:30, Nick Coghlan wrote:
> That said, there are changes that I think are definitely worth making
> due to the concerns you raise:
>
> - the module name should be "_ensurepip" in all versions
> - the PEP should explicitly state that the "don't remove _ensurepip
> and it's whe
On 26 September 2013 09:05, Cameron Simpson wrote:
> On 24Sep2013 09:33, Glenn Linderman wrote:
> | [MRAB]:
> | >> Why not just say something like "Cannot propagate exception..."; it's
> | >> simpler than "Unpropagatable exception...". [...]
> |
> | First one I've heard that accurately and unambi
On 26 September 2013 11:52, Stephen J. Turnbull wrote:
> Donald Stufft writes:
>
> > On Sep 25, 2013, at 7:04 PM, Barry Warsaw wrote:
> >
> > > So, why shouldn't we add enum to the Python 2.7 stdlib? Or any
> > > other new feature? Just be aware that if this PEP is accepted
> > > for Pytho
On 26 September 2013 09:08, Barry Warsaw wrote:
> On Sep 26, 2013, at 09:01 AM, Nick Coghlan wrote:
>
>>Would a leading underscore in the module name make you more comfortable
>>with the idea? It's really intended mostly as a hidden implementation
>>detail of the installers and pyvenv anyway, so c
Donald Stufft writes:
> On Sep 25, 2013, at 7:04 PM, Barry Warsaw wrote:
>
> > So, why shouldn't we add enum to the Python 2.7 stdlib? Or any
> > other new feature? Just be aware that if this PEP is accepted
> > for Python 2.7, the bar will be set much lower for other Really
> > Useful F
On 9/25/2013 5:17 PM, MRAB wrote:
On 26/09/2013 00:05, Cameron Simpson wrote:
[ I've replied to two messages here: Georg's and Glenn's (supporting
MRAB's).
- Cameron
]
On 25Sep2013 08:22, Georg Brandl wrote:
| Am 24.09.2013 00:11, schrieb Greg Ewing:
| > How about something like "Uncaught
On 26/09/2013 00:05, Cameron Simpson wrote:
[ I've replied to two messages here: Georg's and Glenn's (supporting MRAB's).
- Cameron
]
On 25Sep2013 08:22, Georg Brandl wrote:
| Am 24.09.2013 00:11, schrieb Greg Ewing:
| > How about something like "Uncaught exception in __del__
| > method igno
[ I've replied to two messages here: Georg's and Glenn's (supporting MRAB's).
- Cameron
]
On 25Sep2013 08:22, Georg Brandl wrote:
| Am 24.09.2013 00:11, schrieb Greg Ewing:
| > How about something like "Uncaught exception in __del__
| > method ignored"? It explains fairly clearly what has
| > h
On Sep 25, 2013, at 7:15 PM, Barry Warsaw wrote:
> Of course, pip messing with global Python state on a package managed system
> like most Linux distros, is a whole 'nuther happy fun ball of killer
> beeswax. :)
>
> mixing-metaphors-ly y'rs,
> -Barry
(For reals a pip and apt-get playing nice
On Sep 25, 2013, at 07:08 PM, Donald Stufft wrote:
>On Sep 25, 2013, at 7:04 PM, Barry Warsaw wrote:
>
>> So, why shouldn't we add enum to the Python 2.7 stdlib?
>Because with PEP453 you can just ``pip install enum34`` it :)
Of course, pip messing with global Python state on a package managed s
On Sep 25, 2013, at 7:04 PM, Barry Warsaw wrote:
> Another reason to oppose this is what I've heard quite often from people
> regarding Python 2.7. I've been told that many folks are actually really
> happy with using 2.7 precisely because it extremely stable. They don't have
> to worry about
On Sep 26, 2013, at 09:01 AM, Nick Coghlan wrote:
>Would a leading underscore in the module name make you more comfortable
>with the idea? It's really intended mostly as a hidden implementation
>detail of the installers and pyvenv anyway, so calling it "_ensurepip"
>would help make that explicit w
On Sep 25, 2013, at 7:04 PM, Barry Warsaw wrote:
> So, why shouldn't we add enum to the Python 2.7 stdlib? Or any other new
> feature? Just be aware that if this PEP is accepted for Python 2.7, the bar
> will be set much lower for other Really Useful Features That Make Users Lives
> Better.
B
On Sep 25, 2013, at 06:15 PM, Donald Stufft wrote:
>Well I don't think many scripts will be executing ensurepip, maybe i'm wrong,
>but yes it does mean that not all Python 2.7's are alike. Most likely though
>at some point 2.7.XXX is going to be near standard as the 2.7 hold outs stay
>on it and t
On 26 Sep 2013 07:54, "Barry Warsaw" wrote:
>
> On Sep 25, 2013, at 05:33 PM, Donald Stufft wrote:
>
> >I think it should be placed in the source tree for the stable releases.
The
> >reasoning is that 2.7 is going to stick around for a long time.
Immediately
> >this won't be ubiquitous but as time
Hmm, I think I just noticed a subtle bug in the new version that I missed
previously - I believe it may now misclassify a function in an instance
dict as a method.
Would need to try it out to be sure.
Cheers,
Nick.
___
Python-Dev mailing list
Python-Dev
On Sep 25, 2013, at 5:51 PM, Barry Warsaw wrote:
> On Sep 25, 2013, at 05:33 PM, Donald Stufft wrote:
>
>> I think it should be placed in the source tree for the stable releases. The
>> reasoning is that 2.7 is going to stick around for a long time. Immediately
>> this won't be ubiquitous but a
On Sep 26, 2013, at 07:14 AM, Nick Coghlan wrote:
>On 26 Sep 2013 06:53, "Barry Warsaw" wrote:
>>
>> Why does it have to be added to the source tree for stable releases?
>
>If it can get into the installers another way, it doesn't, really. It only
>needs to be in the source tree for 3.4+.
Sure,
On Sep 25, 2013, at 05:33 PM, Donald Stufft wrote:
>I think it should be placed in the source tree for the stable releases. The
>reasoning is that 2.7 is going to stick around for a long time. Immediately
>this won't be ubiquitous but as time goes on you'll be able to be ensured
>that a ``python -
On Sep 25, 2013, at 4:50 PM, Barry Warsaw wrote:
> Why does it have to be added to the source tree for stable releases?
I think it should be placed in the source tree for the stable releases. The
reasoning is that 2.7 is going to stick around for a long time. Immediately
this won't be ubiquitou
On 26 Sep 2013 06:53, "Barry Warsaw" wrote:
>
> On Sep 23, 2013, at 09:15 PM, Nick Coghlan wrote:
>
> >With the last round of updates, I believe PEP 453 is ready for
> >Martin's pronouncement.
>
> I want to raise an objection to PEP's proposal to add this as a new
feature to
> Python 2.7 and 3.3.
On Wed, 25 Sep 2013 16:50:22 -0400
Barry Warsaw wrote:
> On Sep 23, 2013, at 09:15 PM, Nick Coghlan wrote:
>
> >With the last round of updates, I believe PEP 453 is ready for
> >Martin's pronouncement.
>
> I want to raise an objection to PEP's proposal to add this as a new feature to
> Python 2
On Sep 23, 2013, at 09:15 PM, Nick Coghlan wrote:
>With the last round of updates, I believe PEP 453 is ready for
>Martin's pronouncement.
I want to raise an objection to PEP's proposal to add this as a new feature to
Python 2.7 and 3.3. I understand the rationale as stated here:
http://www.pyt
This list is for the developing *of *Python, not it's use. You can try
asking on python-list for some help.
On Wed, Sep 25, 2013 at 4:07 AM, alok bhan wrote:
> Hi All
>
> I need help in installing python development packages (python27-devel) on
> Centos5.8. Upgrading hardware is not an option a
Hi All
I need help in installing python development packages (python27-devel) on
Centos5.8. Upgrading hardware is not an option as of now.
I've installed python2.7 in the same machine by
$ wget --no-check-certificate
http://www.python.org/ftp/python/2.7.3/Python-2.7.3.tgz
$ ./configure --prefix=/
On Wed, Sep 25, 2013 at 6:35 AM, Eli Bendersky wrote:
>
>
>
> On Wed, Sep 25, 2013 at 6:28 AM, Benjamin Peterson wrote:
>
>> 2013/9/25 Eli Bendersky :
>> > Hello,
>> >
>> > Some history (as best as I could collect it) followed by a question:
>> >
>> > Before Python 2.5, the ast stdlib module was
On Wed, Sep 25, 2013 at 6:28 AM, Benjamin Peterson wrote:
> 2013/9/25 Eli Bendersky :
> > Hello,
> >
> > Some history (as best as I could collect it) followed by a question:
> >
> > Before Python 2.5, the ast stdlib module was auto generated by a script
> > named astgen.py from a textual AST defin
On Wed, Sep 25, 2013 at 9:28 AM, Benjamin Peterson wrote:
> 2013/9/25 Eli Bendersky :
> > Hello,
> >
> > Some history (as best as I could collect it) followed by a question:
> >
> > Before Python 2.5, the ast stdlib module was auto generated by a script
> > named astgen.py from a textual AST defin
cc'ing Jeremy Hylton who made the decision to use Zephyr.
On Wed, Sep 25, 2013 at 9:15 AM, Eli Bendersky wrote:
> Hello,
>
> Some history (as best as I could collect it) followed by a question:
>
> Before Python 2.5, the ast stdlib module was auto generated by a script
> named astgen.py from a
2013/9/25 Eli Bendersky :
> Hello,
>
> Some history (as best as I could collect it) followed by a question:
>
> Before Python 2.5, the ast stdlib module was auto generated by a script
> named astgen.py from a textual AST definition in Tools/compiler/ast.txt.
Sorry, what Python 2.4 ast stdlib modul
Hello,
Some history (as best as I could collect it) followed by a question:
Before Python 2.5, the ast stdlib module was auto generated by a script
named astgen.py from a textual AST definition in Tools/compiler/ast.txt.
Since 2.5 (http://www.python.org/dev/peps/pep-0339/) ASTs are part of the
n
35 matches
Mail list logo
