On Wed, Apr 30, 2008 at 10:42 AM, Trent Nelson <[EMAIL PROTECTED]>
wrote:
> > if os.name == "nt":
> > _socketmethods = _socketmethods + ('ioctl',)
> > +_is_windows = True
> > +elif os.name == 'java':
> > +from java.lang import System
> > +_is_windows = 'windows' in System.getProp
> Is there a reliable way to identify 32-bits and 64-bits Windows from within
> Python? I have not found any yet, but it might be a mere oversight on my
> behalf.
>
> The reason I ask is that both return win32, which is most likely a reference
> to the API, even when having installed the 64 bits P
Jared Flatow wrote:
I agree that if your methods are 'clashing' then you are
probably misinheriting, but cooperative methods can be the most natural
way to model certain situations.
I'm not saying that nobody should ever use super, only
that it's not the right thing for the situation I was
> Is there a reliable way to identify 32-bits and 64-bits Windows from
> within Python?
Not that I'm aware of. 'sys.platform=="win32" and "64 bits" in sys.version'
will be reliable when it returns True, but it might be wrong when it returns
False (although when it returns False, things will loo
On 03:49 am, [EMAIL PROTECTED] wrote:
I stand corrected on a few points. You've convinced me that ~/lib/ is
wrong. But I still don't like ~/.local/; not in the last place because
it's not any more local than any other dot files or directories. The
"symmetry" with /usr/local/ is pretty weak, and
-On [20080501 22:27], Barry Warsaw ([EMAIL PROTECTED]) wrote:
>Time is running short to get any new features into Python 2.6 and
>3.0.
Is there a reliable way to identify 32-bits and 64-bits Windows from within
Python? I have not found any yet, but it might be a mere oversight on my
On May 1, 2008, at 9:21 PM, Greg Ewing wrote:
If the classes being mixed clash or overlap in functionality
somehow, the inheriting class needs to override all of the
clashing methods and properties and resolve matters by
delegating to one or another of the inherited classes
(using explicit inhe
I stand corrected on a few points. You've convinced me that ~/lib/ is
wrong. But I still don't like ~/.local/; not in the last place because
it's not any more local than any other dot files or directories. The
"symmetry" with /usr/local/ is pretty weak, and certainly won't help
beginning users.
As
Guido van Rossum schrieb:
On Thu, May 1, 2008 at 11:20 AM, Georg Brandl <[EMAIL PROTECTED]> wrote:
But the other two magical things about super() really bother me too. I
haven't looked at the new super in detail so far (and I don't know how
many others have), and two things are really strikin
On 01:55 am, [EMAIL PROTECTED] wrote:
On Thu, May 1, 2008 at 5:03 PM, <[EMAIL PROTECTED]> wrote:
Hi everybody. I apologize for writing yet another lengthy screed about
a simple directory naming issue. I feel strongly about it but I
encourate anyone who doesn't to simply skip it.
First, s
Paul Moore schrieb:
2008/5/1 Georg Brandl <[EMAIL PROTECTED]>:
Armin Ronacher schrieb:
> I would like to propose a new module for the stdlib for Python 2.6
> and higher: "ast".
If there are no further objections, I'll add this to PEP 361 so that the
proposal doesn't get lost.
Excuse my con
Guido van Rossum schrieb:
On Thu, May 1, 2008 at 5:03 PM, <[EMAIL PROTECTED]> wrote:
On 11:45 pm, [EMAIL PROTECTED] wrote:
> I like this, except one issue: I really don't like the .local
> directory. I don't see any compelling reason why this needs to be
> ~/.local/lib/ -- IMO it should just b
On Thu, May 1, 2008 at 9:31 PM, Brett Cannon <[EMAIL PROTECTED]> wrote:
>
> I just closed the release blocker I created (the
> backwards-compatibility issue with warnings.showwarning() ). I would
> like to add a PendingDeprecationWarning (or stronger) to 2.6 for
> showwarning() implementations
On Thu, May 1, 2008 at 1:26 PM, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> This is a reminder that the LAST planned alpha releases of Python 2.6 and
> 3.0 are scheduled for next Wednesday, 07-May-2008. Please be diligent over
> the next week so
Gustavo Carneiro wrote:
A better question would be, is multiple inheritance good or bad for
programs? :-)
I would say there are good ways of using it, and bad
ways of using it.
In my experience, the good ways occur when the classes
being mixed together are completely independent -- there
is n
Phillip J. Eby wrote:
(Note, by the way, that you cannot safely write an upcall in a mixin
class without super, so it can't safely be done away with, anyway.)
It seems to me you can't safely write one in a mixin class
*with* super either. I know that's what it's supposed to be
for, but I can't
Guido van Rossum wrote:
The
alternative would be to make it a keyword, which seemed excessive
(plus, it would be odd if super() were a keyword when self is not).
If it's really such a useful thing as to warrant so much
magic to support it, then I think it deserves to have a
keyword.
Conversely
Facundo Batista wrote:
Has super() proved more useful than harmful? Which is the value for
Py3 to keep it?
Personally I've found exactly zero use cases for super()
so far in my own code. A couple of times I thought I'd
found one, but it turned out not to do quite what I
wanted, and I ended up
On Thu, May 1, 2008 at 5:03 PM, <[EMAIL PROTECTED]> wrote:
> On 11:45 pm, [EMAIL PROTECTED] wrote:
>
> > I like this, except one issue: I really don't like the .local
> > directory. I don't see any compelling reason why this needs to be
> > ~/.local/lib/ -- IMO it should just be ~/lib/. There's no
On 11:45 pm, [EMAIL PROTECTED] wrote:
I like this, except one issue: I really don't like the .local
directory. I don't see any compelling reason why this needs to be
~/.local/lib/ -- IMO it should just be ~/lib/. There's no need to hide
it from view, especially since the user is expected to manag
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On May 1, 2008, at 7:45 PM, Guido van Rossum wrote:
On Thu, May 1, 2008 at 2:27 PM, Christian Heimes <[EMAIL PROTECTED]>
wrote:
Barry Warsaw schrieb:
This is a reminder that the LAST planned alpha releases of Python
2.6
and 3.0 are scheduled f
On Thu, 1 May 2008, Neal Becker wrote:
> It would be really nice to see support for some other backends, such as Hg
> or bzr (which are both written in python), in addition to svn.
/me starts the clamour for git
--
Cheers,
Leif
___
Python-Dev mailing l
On Thu, May 1, 2008 at 2:00 PM, Christian Heimes <[EMAIL PROTECTED]> wrote:
> Guido van Rossum schrieb:
>
> > I don't see how it could work if any Python code is executed in the
> > module, since code execution uses a dict for globals.
> >
> > Supporting it only for built-in modules seems too bi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On May 1, 2008, at 6:33 PM, Andrew McNabb wrote:
On Thu, May 01, 2008 at 12:55:22PM -0700, Guido van Rossum wrote:
I'm not proud of this, but I don't see a way around it. The
alternative would be to make it a keyword, which seemed excessive
(plus,
On Thu, May 1, 2008 at 4:37 PM, Neal Becker <[EMAIL PROTECTED]> wrote:
> It would be really nice to see support for some other backends, such as Hg
> or bzr (which are both written in python), in addition to svn.
Once it's open source feel free to add those!
--
--Guido van Rossum (home page: ht
On Thu, May 1, 2008 at 2:27 PM, Christian Heimes <[EMAIL PROTECTED]> wrote:
> Barry Warsaw schrieb:
>
> > This is a reminder that the LAST planned alpha releases of Python 2.6
> > and 3.0 are scheduled for next Wednesday, 07-May-2008. Please be
> > diligent over the next week so that none of you
It would be really nice to see support for some other backends, such as Hg
or bzr (which are both written in python), in addition to svn.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
h
On Thu, May 1, 2008 at 4:24 PM, Terry Reedy <[EMAIL PROTECTED]> wrote:
>
> "Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>
> | On Thu, May 1, 2008 at 2:42 PM, Terry Reedy <[EMAIL PROTECTED]> wrote:
> | > As I understood this,one needs a diff to comment on.
> |
On Thu, May 01, 2008 at 12:55:22PM -0700, Guido van Rossum wrote:
>
> I'm not proud of this, but I don't see a way around it. The
> alternative would be to make it a keyword, which seemed excessive
> (plus, it would be odd if super() were a keyword when self is not).
> There were long discussions
On Thu, May 1, 2008 at 2:42 PM, Terry Reedy <[EMAIL PROTECTED]> wrote:
> As I understood this,one needs a diff to comment on.
> I can imagine wanting, or wanting others, to be able to comment on a file
> or lines of files without making a fake diff (of the file versus itself or
> a blank file).
2008/5/1 Georg Brandl <[EMAIL PROTECTED]>:
> Armin Ronacher schrieb:
> > I would like to propose a new module for the stdlib for Python 2.6
> > and higher: "ast".
>
> If there are no further objections, I'll add this to PEP 361 so that the
> proposal doesn't get lost.
Excuse my confusion over p
Barry Warsaw schrieb:
> This is a reminder that the LAST planned alpha releases of Python 2.6
> and 3.0 are scheduled for next Wednesday, 07-May-2008. Please be
> diligent over the next week so that none of your changes break Python.
> The stable buildbots look moderately okay, let's see what we
Guido van Rossum schrieb:
> I don't see how it could work if any Python code is executed in the
> module, since code execution uses a dict for globals.
>
> Supporting it only for built-in modules seems too big an exception.
I came up with the idea in order to replace the setters and getters of
bu
On Thu, May 1, 2008 at 1:20 PM, Christian Heimes <[EMAIL PROTECTED]> wrote:
> What's your opinion on the module properties idea? Do you still like it
> although the property values won't show up in __dict__?
I don't see how it could work if any Python code is executed in the
module, since code e
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
This is a reminder that the LAST planned alpha releases of Python 2.6
and 3.0 are scheduled for next Wednesday, 07-May-2008. Please be
diligent over the next week so that none of your changes break
Python. The stable buildbots look moderately
On Apr 30, 2008, at 5:11 PM, [EMAIL PROTECTED] wrote:
I have a less disruptive counterproposal. How about just starting
to refer to directories (or "folders", or zip entries) with
'__init__.py' in them as "package modules"? A package is-a module
anyway.
That's a good idea.
I belive a m
Guido van Rossum schrieb:
> On Thu, May 1, 2008 at 12:32 PM, Christian Heimes <[EMAIL PROTECTED]> wrote:
>> Guido van Rossum schrieb:
>>
>>> But wouldn't this mean that those properties would no longer be
>> > available in the module's __dict__?
>>
>> Correct. Module properties would behave exact
On Thu, May 1, 2008 at 12:32 PM, Christian Heimes <[EMAIL PROTECTED]> wrote:
> Guido van Rossum schrieb:
>
> > But wouldn't this mean that those properties would no longer be
> > available in the module's __dict__?
>
> Correct. Module properties would behave exactly like instance
> properties. T
2008/5/1 Facundo Batista <[EMAIL PROTECTED]>:
> 2008/5/1, Georg Brandl <[EMAIL PROTECTED]>:
>
> > There may be more implications and surprising behavior surrounding
> this.
> >
> > I know that the implementation is a compromise, but I'd rather see a
> > super()
> > whose full semantics can be
At 04:38 PM 5/1/2008 -0300, Facundo Batista wrote:
Has super() proved more useful than harmful?
For me, yes. I use it all the time. The only time I use
explicit-target upcalls is in __init__ methods, and there usually
only to skip a subclass' init or to explicitly manage a tricky bit of
mu
On Thu, May 1, 2008 at 11:20 AM, Georg Brandl <[EMAIL PROTECTED]> wrote:
> But the other two magical things about super() really bother me too. I
> haven't looked at the new super in detail so far (and I don't know how
> many others have), and two things are really strikingly unpythonic in
> my
2008/5/1, Georg Brandl <[EMAIL PROTECTED]>:
> There may be more implications and surprising behavior surrounding this.
>
> I know that the implementation is a compromise, but I'd rather see a
> super()
> whose full semantics can be explained to programmers without using to
> "cell variable",
Guido van Rossum schrieb:
> But wouldn't this mean that those properties would no longer be
> available in the module's __dict__?
Correct. Module properties would behave exactly like instance
properties. They don't appear on the instance's __dict__ attribute, too.
By the way I was astonished that
Armin Ronacher schrieb:
The super() thing is a case of practicality beats purity. Note that
you pay a small but measurable cost for the implicit __class__ (it's
implemented as a "cell variable", the same mechanism used for nested
scopes) so we wouldn't want to introduce it unless it is used.
I
Armin Ronacher schrieb:
Hi all,
I would like to propose a new module for the stdlib for Python 2.6
and higher: "ast". The motivation for this module is the pending
deprecation for compiler.ast which is widely used (debugging,
template engines, code coverage etc.). _ast is a very solid module
Some of you may have seen a video recorded in November 2006 where I
showed off Mondrian, a code review tool that I was developing for
Google (http://www.youtube.com/watch?v=sMql3Di4Kgc). I've always hoped
that I could release Mondrian as open source, but it was not to be:
due to its popularity insi
Hi,
Guido van Rossum python.org> writes:
> The staticmethod thing isn't new; that's also the case in 2.x.
staticmethod hasn't changed, method has. In the past Class.method gave
you a unbound method, now you get a function back as if it was a static
method.
> The super() thing is a case of prac
47 matches
Mail list logo
