> [Gregory P. Smith]
> > or make it even uglier to hide from pychecker by writing that as:
> >
> > exec("""
> > try:
> > set
> > except NameError:
> > from sets import Set as set
> > """)
>
> I presume that was somewhat tongue-in-cheek, but if it wasn't, please
> reconsider. Modulefinder
[Bob Ippolito]
try:
set
except NameError:
from sets import Set as set
You don't need the rest.
[Skip Montanaro]
>>> Sure, but then pychecker bitches about a statement that appears to
>>> have no effect. ;-)
[Bob Ippolito]
>> Well then fix PyChecker to look
On Fri, Mar 11, 2005 at 06:47:11PM -0500, Bob Ippolito wrote:
>
> On Mar 11, 2005, at 2:26 PM, Skip Montanaro wrote:
>
> >
> >Bob> try:
> >Bob> set
> >Bob> except NameError:
> >Bob> from sets import Set as set
> >
> >Bob> You don't need the rest.
> >
> >Sure, but the
On Mar 11, 2005, at 2:26 PM, Skip Montanaro wrote:
Bob> try:
Bob> set
Bob> except NameError:
Bob> from sets import Set as set
Bob> You don't need the rest.
Sure, but then pychecker bitches about a statement that appears to
have no
effect. ;-)
Well then fix PyChecker t
Bob> try:
Bob> set
Bob> except NameError:
Bob> from sets import Set as set
Bob> You don't need the rest.
Sure, but then pychecker bitches about a statement that appears to have no
effect. ;-)
Skip
___
Python-Dev mailing
On Thu, 2005-03-10 at 23:46, Glyph Lefkowitz wrote:
> That way instead of multi-line "except NameError" tests all over the
> place you can simply have one-liner boilerplate for every module in your
> project:
>
> 'from py24compat import *'
>
> Easy to grep/sed for when you're ready to st
On Mar 10, 2005, at 11:46 PM, Glyph Lefkowitz wrote:
Bob Ippolito wrote:
try:
set
except NameError:
from sets import Set as set
Syntactical variations notwithstanding, I think it's a common desire
to want to run on at least the last few versions of Python, but take
advantage of improvemen
Bob Ippolito wrote:
try:
set
except NameError:
from sets import Set as set
Syntactical variations notwithstanding, I think it's a common desire to
want to run on at least the last few versions of Python, but take
advantage of improvements and not emit deprecation warnings on the
latest a
On Mar 9, 2005, at 8:03 AM, Skip Montanaro wrote:
Anthony> Goal 4: Try and prevent something like
Anthony> try:
Anthony> True, False
Anthony> except NameError:
Anthony> True, False = 1, 0
Anthony> from e
Anthony> Goal 4: Try and prevent something like
Anthony> try:
Anthony> True, False
Anthony> except NameError:
Anthony> True, False = 1, 0
Anthony> from ever ever happening again.
I will point out that
Guido van Rossum wrote:
On Wed, 09 Mar 2005 10:38:12 -0500, Jim Fulton <[EMAIL PROTECTED]> wrote:
+1 (wish * could say +sys.maxint).
Anthony gets my +1 too, which then adds up to sys.maxint. :-)
+1!
I hope this mailing list runs on python2.2+, or the discussion has to
stop now due to OverflowErro
Anthony Baxter <[EMAIL PROTECTED]> writes:
> My google-fu returned, and I found the piece I was looking for earlier.
> This discusses (from an internal Sun perspective) some of the problems
> with Java. They make quite a big deal about the problem of changing
> code across minor releases. I recall
My google-fu returned, and I found the piece I was looking for earlier.
This discusses (from an internal Sun perspective) some of the problems
with Java. They make quite a big deal about the problem of changing
code across minor releases. I recall (re)reading this at some point and it
helped me cla
On Wed, 09 Mar 2005 10:38:12 -0500, Jim Fulton <[EMAIL PROTECTED]> wrote:
> +1 (wish * could say +sys.maxint).
Anthony gets my +1 too, which then adds up to sys.maxint. :-)
> To emphasize:
>
> - We want people to update to bug fix releases quickly. For people
>to do that, they need to know t
+1 (wish * could say +sys.maxint).
To emphasize:
- We want people to update to bug fix releases quickly. For people
to do that, they need to know the risk of breakage is low. Reducing the
scope of the release is important for that.
- Python has gotten much better at this than it used to be. I
On Wed, 2005-03-09 at 07:17, Anthony Baxter wrote:
> So it's only fair that I write down my rationale for why I'm being anal
> about the no-new-features approach. Comments are more than welcome -
> ideally, after discussion, I'll put some more words in the bugfix PEP.
I applaud your strictness Ant
So it's only fair that I write down my rationale for why I'm being anal
about the no-new-features approach. Comments are more than welcome -
ideally, after discussion, I'll put some more words in the bugfix PEP.
Goal 1: When we cut a bugfix release, people will upgrade to it.
- This helps the us
17 matches
Mail list logo
