Hi Martin,
On 6/29/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> We should remove/change this comment. It is utterly misleading.
To a warning/error stating that you miss a compiler?
> I meant to leave this as a per-shell choice. If you set MSSdk, you
> indicate that the environment you crea
Bruce Christensen wrote:
> In developing a cPickle module for IronPython that's as compatible as
> possible with CPython, these questions have come up:
[I wish you were allowed to read the source code of Python]
> - Where are object.__reduce__ and object.__reduce_ex__ defined, and how
> does co
In developing a cPickle module for IronPython that's as compatible as
possible with CPython, these questions have come up:
- Where are object.__reduce__ and object.__reduce_ex__ defined, and how
does copy_reg._reduce_ex fit into the picture? PEP 307 states that the
default __reduce__ implementat
On 6/29/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> I disagree. You can get everything you need with a dict, and making
> sets a part of the language (besides being a builtin type), would
> necessarily add more overhead and maintenance to the language for little
> gain. If you need set-like f
"Alexander Belopolsky" <[EMAIL PROTECTED]> wrote:
> On 6/29/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> >... dict is more basic, set is just a special case of
> > dict for performance reasons. Also, dict is used to define and implement
> > the language itself, set is "just" a predefined typ
Martin v. Löwis wrote:
> Greg Ewing wrote:
>> BTW, I'm not sure if 'xturtle' is such a good name.
>> There's a tradition of X Windows executables having
>> names starting with 'x', whereas this is presumably
>> platform-independent.
>>
>> Maybe 'turtleplus' or something?
>
> When it goes into Pyth
> Real-world usage case for import __main__?
Typically for inter-module communication. A standard name (such as
lobby, or __settings__) would work as well, but __main__ is what we
have, for backwards compatibility.
-jJ
___
Python-Dev mailing list
Pytho
On 6/29/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>... dict is more basic, set is just a special case of
> dict for performance reasons. Also, dict is used to define and implement
> the language itself, set is "just" a predefined type.
>
I guess it can be seen either way, just as a chicken a
Alexander Belopolsky wrote:
> I feel that set is a more basic object than dict
I don't feel that way; dict is more basic, set is just a special case of
dict for performance reasons. Also, dict is used to define and implement
the language itself, set is "just" a predefined type.
> but dictobject m
A.M. Kuchling wrote:
> This thought was sparked by the piece on failure-oblivious computing
> in today's Linux Weekly News about this paper:
> http://www.usenix.org/events/osdi04/tech/rinard.html.
The paper is also available from one of the authors at
http://www.cag.lcs.mit.edu/~rinard/paper/osd
Jeroen Ruigrok van der Werven wrote:
> I am testing/working on some Python code on Windows.
> During this I encounter some issues where I am being told I don't have
> the .Net SDK installed. So I started investigating this issue and came
> to http://www.vrplumber.com/programming/mstoolkit/index.htm
On 6/29/06, A.M. Kuchling <[EMAIL PROTECTED]> wrote:
On Thu, Jun 29, 2006 at 11:48:36AM -0700, Brett Cannon wrote:> My worry, as has been from the start, is containing 'file'. The ``del> __builtins__`` bug for 'rexec' started me as skittish towards hiding stuff
> from the built-in namespace. And
On Thu, Jun 29, 2006 at 11:48:36AM -0700, Brett Cannon wrote:
> My worry, as has been from the start, is containing 'file'. The ``del
> __builtins__`` bug for 'rexec' started me as skittish towards hiding stuff
> from the built-in namespace. And knowing how easy it tends to be to get at
> objects
I have gotten some questions from people about why cripple 'file' (and probably 'socket' if they cared), asking whey I didn't just remove the 'file' built-in from built-ins. Problem is that I still want to provide some protection for files.
So an option I have been thinking of is making sure 'file
Aahz wrote:
> On Thu, Jun 29, 2006, Scott David Daniels wrote:
>> .
> I'm hoping this was a typo of an e-mail address for sending, because
> this is not appropriate for python-dev.
This absolutely was a matter of clicking the wrong spot. I completely
agree it would be inappropriate for this forum
Christos Georgiou wrote:
> I haven't followed the complete discussion about once, but I would assume it
> would be used as such:
>
> once =
>
> that is, always an assignment, with the value stored as a cellvar, perhaps,
> on first execution 0f the code.
>
> Typically I would use it as:
>
>
On 6/28/06, Mark Hammond <[EMAIL PROTECTED]> wrote:
Bob writes:> I don't know how _javascript_ is doing it yet. The critical thing> for me for this month was trying to come up with a security model.I don't fully understand how JS does it either, certainly not in any detail.
I know that it uses the
Georg Brandl wrote:
> In followup to a clpy discussion, should the docs contain
> a note that property can be used as a decorator for creating
> read-only properties?
feel free to steal the extended example and the read-only example from
the pyref wiki:
http://pyref.infogami.com/property
On Thursday 29 June 2006 14:31, Georg Brandl wrote:
> In followup to a clpy discussion, should the docs contain
> a note that property can be used as a decorator for creating
> read-only properties?
I certainly wouldn't object. This is a very handy feature of property that I
use frequently.
Guido van Rossum wrote:
>> Real-world usage case for import __main__? Otherwise, I say screw it
>> :) [...] My personal argument is that if __name__ == '__main__' is
>> totally counter-intuitve and unpythonic. It also proves my memory:
>> after many years, I still have to think a couple of seconds
Fredrik Lundh pythonware.com> writes:
> given that CPython has about a dozen Fini functions, what exactly is it
> that makes PySet_Fini so problematic ?
>
I have not been bitten by the other _Fini yet. ;-)
I was bitten by PySet_Fini when I tried to replace the "interned" dict with a
set. Sin
The PyGIL_ function prototypes in the header files are not protected
within #ifdef WITH_THREADS ... #endif blocks.
I think it is worth do implement this although currently I don't have
time for that.
Thanks,
Thomas
___
Python-Dev mailing list
Python-De
On Thu, Jun 29, 2006, Scott David Daniels wrote:
>
> Rush Limbaugh was detained and questioned for transporting a possible
> illegal Viagra prescription into the country.
>
> Well... a least we know his back is feeling better.
I'm hoping this was a typo of an e-mail address for sending, because
t
In followup to a clpy discussion, should the docs contain
a note that property can be used as a decorator for creating
read-only properties?
Georg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsub
On 6/29/06, Giovanni Bajo <[EMAIL PROTECTED]> wrote:
> Real-world usage case for import __main__? Otherwise, I say screw it :)
[...]
> My personal argument is that if __name__ == '__main__' is totally
> counter-intuitve and unpythonic. It also proves my memory: after many years,
> I still have to t
Rush Limbaugh was detained and questioned for transporting a possible
illegal Viagra prescription into the country.
Well... a least we know his back is feeling better.
-- Scott David Daniels
[EMAIL PROTECTED]
___
Python-Dev mailing list
Python-Dev@pyth
> yeah, but what are they? integers? strings? names without an associated
> value?
> how do you create new labels? where are they stored? who keeps track of
> them?
In this scheme, dispatch tables can be considered to be reverse-lookup
namespaces. Where a regular namespace is used to look
Gregor Lingl wrote:
> Yes,, and I have some ideas in this respect, but mainly a prioncipal
> question. I read about
> using doctest and unittest, but how does one devise
> automatic test suites for graphical output. In the end it depends on how
> it looks like.
There are a few options here.. Tw
Gregor Lingl wrote:
> One question in this respect - how important do you consider
> backward compatibility. When designing a new module the requirement
> backward copmpatibility can have a big impact on the code although it
> may in some parts be questionable. As an example let me mention the
> r
> >> what's a "label" ?
> >
> > In your example, RED, GREEN, and BLUE. colours provides a mapping
> > from values to labels/cases, and the switch statement provides a
> > mapping from labels/cases to code. Sorry about introducing a new term
> > without saying anything about it.
>
> yeah, but what
Eric Sumner wrote:
>> what's a "label" ?
>
> In your example, RED, GREEN, and BLUE. colours provides a mapping
> from values to labels/cases, and the switch statement provides a
> mapping from labels/cases to code. Sorry about introducing a new term
> without saying anything about it.
yeah, but
Martin v. Löwis schrieb:
> Gregor Lingl wrote:
>
> ...
>> (Who reviewed it? This is a _newly_added_ function -
>> did nobody try it out yet? Incredible!!)
>>
>
> Apparently not. Thanks for pointing that out; Georg (who committed the
> patch originally) just fixed it in r47151.
>
> This illu
> >> You mean something like this?:
> >>
> >>switch x in colours:
> >> case RED:
> >> # whatever
> >> case GREEN:
> >> # whatever
> >> case BLUE:
> >> # whatever
> >>
> >> I think Guido's right. It doesn't solve the underlying problem because the
> >> c
On Thursday 29 June 2006 20:56, Nick Coghlan wrote:
> Guido van Rossum wrote:
> > On 6/28/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> >> The workaround to replace __name__ with __module_name__ in order
> >> to enable
> >> relative imports turned out to be pretty ugly, so I also worked
> >> up a p
Eric Sumner wrote:
>> You mean something like this?:
>>
>>switch x in colours:
>> case RED:
>> # whatever
>> case GREEN:
>> # whatever
>> case BLUE:
>> # whatever
>>
>> I think Guido's right. It doesn't solve the underlying problem because the
>> compi
On 6/29/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> You mean something like this?:
>
>switch x in colours:
> case RED:
> # whatever
> case GREEN:
> # whatever
> case BLUE:
> # whatever
>
> I think Guido's right. It doesn't solve the underlying problem
I haven't followed the complete discussion about once, but I would assume it
would be used as such:
once =
that is, always an assignment, with the value stored as a cellvar, perhaps,
on first execution 0f the code.
Typically I would use it as:
def function(a):
once pathjoin = os.path.jo
I am testing/working on some Python code on Windows.
During this I encounter some issues where I am being told I don't have
the .Net SDK installed. So I started investigating this issue and came
to http://www.vrplumber.com/programming/mstoolkit/index.html
I also checked the latest repository versi
Gregor Lingl wrote:
> So, if you can't accept that offer - now, or even ever - , because it
> contradicts your rules, that's o.k. But it's not 'my cause'. I
> concieve it to be the community's cause.
All "we" said is that we cannot integrate it now, as a policy matter.
Nobody said it can't be in
Guido van Rossum wrote:
> So we have what seems to be an impasse. Some people would really like
> once-expressions to be captured at def-time rather than at the first
> execution per def; this is the only way to use it so solve the "outer
> loop variable reference" problem. Others would really hate
Anthony Baxter wrote:
> On Wednesday 28 June 2006 20:41, nick.coghlan wrote:
>> Author: nick.coghlan
>> Date: Wed Jun 28 12:41:47 2006
>> New Revision: 47142
>>
>> Modified:
>>python/trunk/Doc/lib/librunpy.tex
>>python/trunk/Lib/runpy.py
>>python/trunk/Lib/test/test_runpy.py
>> Log:
>>
Eric Sumner wrote:
>>> Forget subroutines for a moment - the main point of the thread was the
>>> idea that the dispatch table was built explicitly rather than
>>> automatically - that instead of arguing over first-use vs.
>>> function-definition, we let the user decide. I'm sure that my specific
>
Nick Coghlan wrote:
> Writing modules that use the approach but want to work with both 2.5
> and 2.6 becomes a little more annoying - such modules have to finish
> with the coda:
>
> if __name__ == '__main__':
>from sys import version_info, argv
>if version_info < (2, 6):
>sys.exit
Greg Ewing wrote:
> Nick Coghlan wrote:
>
>> By 'current namespace' I really do mean locals() - the cell objects
>> themselves
>> would be local variables from the point of view of the currently
>> executing code.
>
> This is wrong. Cells are *parameters* implicitly passed
> in by the calling f
Nick Coghlan wrote:
> I consider the proposed import change (looking for __module_name__ in the
> main
> module) a bug fix for the interaction between PEP 338 and 328, but I'll hold
> off on committing it until I get the OK from yourself or Neal (and put the
> patch on SF in the meantime).
Or
Anthony Baxter wrote:
> Anyway, this is the current thinking. Am I being too dogmatic here?
> Comments solicited.
Seems like a fair policy to me.
> As far as people to sign off on things, Neal, myself or Guido should
> be the ones to do it. Course, Guido will probably decide he doesn't
> want
Giovanni Bajo wrote:
> Guido van Rossum wrote:
>
This is where I wonder why the "def __main__()" PEP was rejected in
the first place. It would have solved this problem as well.
>>> Could this be reconsidered for Py3k?
>> You have a point.
>
> AFAICT, there's nothing preventing it from b
On 6/28/06, Gregor Lingl <[EMAIL PROTECTED]> wrote:
> I made xturtle.py and that was a big effort. And I offer it to replace
> turtle.py. I do this because I'm a Python enthusiast and I want a better
> Python. (And I know very well that my contribution is rather marginal).
> We all, I think, have t
Guido van Rossum wrote:
> On 6/28/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>
>> The workaround to replace __name__ with __module_name__ in order to
>> enable
>> relative imports turned out to be pretty ugly, so I also worked up a
>> patch to
>> import.c to get it to treat __module_name__ as a
[EMAIL PROTECTED] wrote:
> One other thought -- at PyCon, I talked with a group of
> educators. While they needed some minor tweaks to the Turtle
> module, there were no requests for an extensive rewrite or a
> fatter API. The name of the game was to have a single module
> with a minimal toolset
50 matches
Mail list logo
