Am 24.09.2013 00:11, schrieb Greg Ewing:
Antoine Pitrou wrote:
Yes, but I agree with Greg that unraisable is wrong. After all, it
was raised, and it can even be caught by the programmer (inside
__del__).
How about something like Uncaught exception in __del__
method ignored? It explains
Am 23.09.2013 00:03, schrieb Guido van Rossum:
AFAIU, the proposal is to embed parts of the concise docstring into the
more
verbose .rst documentation.
I still think that's a bad idea. Someone editing the docstring may introduce a
terminology change or some other
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
2013/9/25 Eli Bendersky eli...@gmail.com:
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
cc'ing Jeremy Hylton who made the decision to use Zephyr.
On Wed, Sep 25, 2013 at 9:15 AM, Eli Bendersky eli...@gmail.com 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
On Wed, Sep 25, 2013 at 9:28 AM, Benjamin Peterson benja...@python.orgwrote:
2013/9/25 Eli Bendersky eli...@gmail.com:
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
On Wed, Sep 25, 2013 at 6:28 AM, Benjamin Peterson benja...@python.orgwrote:
2013/9/25 Eli Bendersky eli...@gmail.com:
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
On Wed, Sep 25, 2013 at 6:35 AM, Eli Bendersky eli...@gmail.com wrote:
On Wed, Sep 25, 2013 at 6:28 AM, Benjamin Peterson benja...@python.orgwrote:
2013/9/25 Eli Bendersky eli...@gmail.com:
Hello,
Some history (as best as I could collect it) followed by a question:
Before Python
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
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 rajalo...@gmail.com wrote:
Hi All
I need help in installing python development packages (python27-devel) on
Centos5.8. Upgrading hardware is
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:
On Wed, 25 Sep 2013 16:50:22 -0400
Barry Warsaw ba...@python.org 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
On 26 Sep 2013 06:53, Barry Warsaw ba...@python.org 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
On Sep 25, 2013, at 4:50 PM, Barry Warsaw ba...@python.org 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
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 -m
On Sep 26, 2013, at 07:14 AM, Nick Coghlan wrote:
On 26 Sep 2013 06:53, Barry Warsaw ba...@python.org 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+.
On Sep 25, 2013, at 5:51 PM, Barry Warsaw ba...@python.org 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
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
On 26 Sep 2013 07:54, Barry Warsaw ba...@python.org 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
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 time
On Sep 25, 2013, at 7:04 PM, Barry Warsaw ba...@python.org 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
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 while
On Sep 25, 2013, at 7:04 PM, Barry Warsaw ba...@python.org 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
On Sep 25, 2013, at 07:08 PM, Donald Stufft wrote:
On Sep 25, 2013, at 7:04 PM, Barry Warsaw ba...@python.org 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
On Sep 25, 2013, at 7:15 PM, Barry Warsaw ba...@python.org 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
virtualenv invocation not shown
[ I've replied to two messages here: Georg's and Glenn's (supporting MRAB's).
- Cameron
]
On 25Sep2013 08:22, Georg Brandl g.bra...@gmx.net wrote:
| Am 24.09.2013 00:11, schrieb Greg Ewing:
| How about something like Uncaught exception in __del__
| method ignored? It explains fairly clearly
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 g.bra...@gmx.net wrote:
| Am 24.09.2013 00:11, schrieb Greg Ewing:
| How about something like Uncaught exception in __del__
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 g.bra...@gmx.net wrote:
| Am 24.09.2013 00:11, schrieb Greg Ewing:
| How about something
Donald Stufft writes:
On Sep 25, 2013, at 7:04 PM, Barry Warsaw ba...@python.org 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
On 26 September 2013 09:08, Barry Warsaw ba...@python.org 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
On 26 September 2013 11:52, Stephen J. Turnbull step...@xemacs.org wrote:
Donald Stufft writes:
On Sep 25, 2013, at 7:04 PM, Barry Warsaw ba...@python.org 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
On 26 September 2013 09:05, Cameron Simpson c...@zip.com.au wrote:
On 24Sep2013 09:33, Glenn Linderman v+pyt...@g.nevcal.com wrote:
| [MRAB]:
| Why not just say something like Cannot propagate exception...; it's
| simpler than Unpropagatable exception [...]
|
| First one I've heard
On 26 September 2013 14:30, Nick Coghlan ncogh...@gmail.com 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
Hi Nick,
On Thu, Sep 26, 2013 at 6:59 AM, Nick Coghlan ncogh...@gmail.com 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
34 matches
Mail list logo
