Ka-Ping Yee wrote:
> Fredrik's NameError-based proposal (exit when there's an exception
> with no tb_next that says "name 'exit' is not defined") causes the
> interpreter to quit when you enter any expression involving 'exit'.
>
> print exit # seems surprising
> [3, 4, 5,
Alex Martelli wrote:
> On Dec 27, 2005, at 12:45 PM, Valentino Volonghi aka Dialtone wrote:
> ...
>> any(iterable, test=bool) and all(iterable, test=bool)
> ...
>> any(some_objects, test=operator.attrgetter('some_attribute'))
>
> Why would that be better than
> any(o.some_attribute for o in
Jim Jewett wrote:
> Jim Fulton asked how this canonical ordering
> should be defined.
>
> The obvious answer is "Just like the __lt__
> operator today". But it doesn't actually *need*
> to be that sensible, if there are strong reasons
> to prefer a simpler ordering.
>
> The more I think about i
--- Adal Chiriliuc <[EMAIL PROTECTED]> wrote:
> Then you need to run mt.exe to embedd the manifest:
> mt.exe /outputresource:"cctbx_math_ext.pyd;#2" /manifest
> cctbx_math_ext.pyd.manifest
That is the magic trick! After applying the mt command to all our extensions
most of our unit tests work even
On Wed, 28 Dec 2005, Fredrik Lundh wrote:
> Ka-Ping Yee wrote
> > It sounds to me like what is being proposed amounts to essentially
> > "promote sys.exit to a builtin".
> no, what's being proposed is what the subject says: a quit/exit command
> that actually quits, instead of printing a "you didn'
Fredrik> a quit/exit command that actually quits, instead of printing a
Fredrik> "you didn't say please!" message.
I like Fredrik's idea more and more. Without my Unix bifocals it wouldn't
occur to me that Ctrl-D is the way to exit. Knowing Ctrl-Z is EOF on
Windows, it wouldn't occur to
Bob Ippolito wrote:
> I don't see the harm in a "key" argument like sorted has, but without
> a key argument it could be extended to take more arguments like max/
> min do for convenience. e.g. any(a, b, c) instead of any((a, b, c)).
Hmm, I think you just found the use case for fixing the curr
[Martin Blais]
> Now, it's not all about storage space. What about front-insertion?
> Everytime I have to type L.insert(0, bli), somewhere that I know runs
> "often" I cringe. If I had lists I would be able to express my
> thoughts more clearly in the computer program. Right now, I cringe,
> and
Dear Armin,
> You are mentioning confusingly many levels of PyPy for this argument.
This is true, I didn't want to care.
> This is not directly related to static analysis nor to the JIT. The
> point is just that while a Python program runs, the implementation can
> decide to start using a deque
> Of course I already knew all the alternatives using map and the generator
> expression, but I felt like mine was clearer for a reader, this is
> probably true but not enough to justify the change.
If there is to be any enhancement, I think I would prefer it to be an
enhancement to map, so that m
Today, x < y will return a consistent result,
even if the two objects are not comparable
in any meaningful manner.[*] The current plan
for Python 3 is to instead raise TypeError.
If this really needs to be changed (and I don't
think it does), then there should still be a s
Brett Cannon wrote:
>And Tim had a good point about PDAs and such; how are they supposed to
>exit? What if someone picked up Python for their Nokia S60 phone and
>tried to exit from the interpreter? Unless Nokia has tweaked
>something I don't know how they would know to exit without knowing
>abo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ka-Ping Yee wrote:
> [...]
> (b) If more handholding seems like a good idea, then:
>
> class ExitHatch:
> def __call__(self): sys.exit()
> def __repr__(self): return ''
> __builtins__.exit = __builtins__.qui
Ka-Ping Yee wrote
> It sounds to me like what is being proposed amounts to essentially
> "promote sys.exit to a builtin".
no, what's being proposed is what the subject says: a quit/exit command
that actually quits, instead of printing a "you didn't say please!" message.
_
On 12/27/05, Ka-Ping Yee <[EMAIL PROTECTED]> wrote:
> It sounds to me like what is being proposed amounts to essentially
> "promote sys.exit to a builtin". So why not do that?
>
> I see two options. Either:
>
> (a) Simply let __builtins__.exit = sys.exit. Then we get:
>
> >>> exit
>
On Tuesday, December 27, 2005 Ralf W. Grosse-Kunstleve wrote:
> Sorry, the manifests are new to me. How can I check if the manifest is
> correctly embedded?
> FWIW: I already tried copying the manifest into the directory with the
> extensions.
To check if you have a manifest you need to use a too
Adal Chiriliuc wrote:
> I have a solution proposal (I have no idea if it's feasible): why not
> intercept "exit" and "quit" in the interpreter command line parser? A
> simple regexp should do. Is the interactive interpreter implemented in
> Python or on the C side?
In short: it's not feasible. Ple
On Wednesday, December 28, 2005 Fredrik Lundh wrote:
> WinXP or WinXP+Cygwin ? here's what I get:
Normal WinXP, without Cygwin.
>>python
> Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)] on win32
> Type "help", "copyright", "credits" or "license" for more information.
It sounds to me like what is being proposed amounts to essentially
"promote sys.exit to a builtin". So why not do that?
I see two options. Either:
(a) Simply let __builtins__.exit = sys.exit. Then we get:
>>> exit
which may be enough of a clue that you type "exit
Adal Chiriliuc wrote:
> Python 2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310 32 bit (Intel)] on win32
> Type "help", "copyright", "credits" or "license" for more information.
> >>> exit
> 'Use Ctrl-Z plus Return to exit.'
> >>>
>
> I've just tried Ctrl+Z (plus Return) and some variations on Win X
On Dec 27, 2005, at 5:48 PM, Valentino Volonghi aka Dialtone wrote:
> On Tue, Dec 27, 2005 at 01:50:37PM -0800, Alex Martelli wrote:
>
> I'll answer here for all the people who kindly answered.
>
>> Why would that be better than
>> any(o.some_attribute for o in some_objects)
>> ?
>
> I think it's
On Tue, Dec 27, 2005 at 01:50:37PM -0800, Alex Martelli wrote:
I'll answer here for all the people who kindly answered.
> Why would that be better than
> any(o.some_attribute for o in some_objects)
> ?
I think it's because lately I've been using common lisp a lot and the approach
with the test f
Python 2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> exit
'Use Ctrl-Z plus Return to exit.'
>>>
I've just tried Ctrl+Z (plus Return) and some variations on Win XP and
it doesn't work! Ctrl+D does.
Hans Nowak wrote:
> I'm not sure what to say to that. Do you really want to type "raise
> SystemExit" every time you want to exit the interpreter? (Your answer
> would probably be something like "No -- that's why I use Ctrl-D". But
> that wouldn't really get us anywhere, would it?)
Well... I
Ralf W. Grosse-Kunstleve wrote:
> I wasn't sure about that. In the transition from VC 6 to VC 7.x we didn't
> have compatibility problems. I was hoping this trend continues ...
That was by pure luck only. Other people did have problems.
> If that's not the case we will need two Python 2.5 install
Adal Chiriliuc wrote:
> Python uses LoadLibraryEx with the LOAD_WITH_ALTERED_SEARCH_PATH flag
> which means that DLLs used by the extension will be searched
> IN THE EXTENSION FOLDER and not on PATH.
Can you please refer to the part of the documentation that documents
that PATH is not searched? In
Hans Nowak wrote:
> My point is that there is currently no acceptable, universal way to exit
> the interpreter. Again, it's not that big of a deal... but it seems
> silly that something apparently trivial like that cannot be done right.
it's the usual problem: getting enough developers to agree
[Martin v. Löwis]
>> If you want to type something consistently across platforms, you can
>> currently do
>>
>> >>>raise SystemExit
[Hans Nowak]
> I'm not sure what to say to that. Do you really want to type "raise
> SystemExit" every time you want to exit the interpreter? (Your answer
> would p
--- Adal Chiriliuc <[EMAIL PROTECTED]> wrote:
> Python uses LoadLibraryEx with the LOAD_WITH_ALTERED_SEARCH_PATH flag
> which means that DLLs used by the extension will be searched
> IN THE EXTENSION FOLDER and not on PATH.
>
> Try putting msvcp80.dll right next to your extension DLL.
I tried th
On Dec 27, 2005, at 12:45 PM, Valentino Volonghi aka Dialtone wrote:
...
> any(iterable, test=bool) and all(iterable, test=bool)
...
> any(some_objects, test=operator.attrgetter('some_attribute'))
Why would that be better than
any(o.some_attribute for o in some_objects)
?
> def zerop(x):
Valentino Volonghi aka Dialtone wrote:
> What I would like to ask, before it's too late, is if it's possible to add an
> optional test argument.
I don't see why: you can easily synthesize that with map/imap.
> These would be the new proposed APIs. The usecase is to be able to extract
> attributes
--- "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Ralf W. Grosse-Kunstleve wrote:
> > I am using a Visual Studio 2005 Professional installation. I also ran
> > vcredist_x86.exe. Moving msvc[mpr]80.dll to a directory on PATH didn't
> > help. However, standalone executables work OK without any gymn
Martin v. Löwis wrote:
> If you want to type something consistently across platforms, you can
> currently do
>
raise SystemExit
I'm not sure what to say to that. Do you really want to type "raise
SystemExit" every time you want to exit the interpreter? (Your answer
would probably be somet
Fredrik Lundh wrote:
> (it would be nice if it was possible to detect "interactive mode" when the
> site
> code runs, though. does anyone know if that's possible ?)
I believe checking sys.argv==[''] is a nearly reliable test (the only
other case where I could make it happen is when the script is
Hans Nowak wrote:
> Granted, it's not a big problem, but it *is* annoying. IMHO, it would
> be more useful if you could just type 'exit' or 'quit' (like in many
> other interpreters) and be done with it, rather than having to remember
> the correct key combination. (A key combination which has no
I see that Python 2.5 will include a simple implementation of any/all.
What I would like to ask, before it's too late, is if it's possible to add an
optional test argument.
any(iterable, test=bool) and all(iterable, test=bool)
These would be the new proposed APIs. The usecase is to be able to ex
Martin v. Löwis wrote:
> The thing is there primarily for people who *don't* know how to
> program in Python. If they knew, they knew how to get out of it;
> they wouldn't type "quit()" but simply Ctrl-D.
Except that on Windows, it's Ctrl-Z. This can be quite confusing when
you regularly use Py
[EMAIL PROTECTED] wrote:
> Fredrik> whaddya think?
>
> We're going to wind up with the same problem that spawned the atexit module:
> multiple code sources wanting to fiddle with sys.excepthook step on one
> another's toes.
in this case, I'm not sure it matters that much. if you add your own
Martin> So if they do
>>> quit
Martin> they are just as confused as if they got a name error.
Probably more so...
Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
Martin v. Löwis wrote:
> M.-A. Lemburg wrote:
>>> Here's a rough draft:
>>>
>>>def textopen(name, mode="r", encoding=None):
>>>if "U" not in mode:
>>>mode += "U"
>>
>> The "U" is not needed when opening files using codecs -
>> these always break lines using .splitlines() whi
Python uses LoadLibraryEx with the LOAD_WITH_ALTERED_SEARCH_PATH flag
which means that DLLs used by the extension will be searched
IN THE EXTENSION FOLDER and not on PATH.
Try putting msvcp80.dll right next to your extension DLL.
It is a little strange that it is not loaded directly from the Wind
On Tue, Dec 27, 2005, Martin Blais wrote:
>
> Now, it's not all about storage space. What about front-insertion?
> Everytime I have to type L.insert(0, bli), somewhere that I know runs
> "often" I cringe. If I had lists I would be able to express my
> thoughts more clearly in the computer progra
M.-A. Lemburg wrote:
>>Here's a rough draft:
>>
>>def textopen(name, mode="r", encoding=None):
>>if "U" not in mode:
>>mode += "U"
>
>
> The "U" is not needed when opening files using codecs -
> these always break lines using .splitlines() which
> breaks lines according to
On 12/26/05, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> > A "flat" list or tuple would certainly be more space-efficient up to
> > this point. But when the graph branches, the 2-tuple representation
> > allows *sharing* the common path suffix (which may be very long!):
> ...
> > If there's an N-w
Phillip J. Eby wrote:
> At 04:20 PM 12/27/2005 +0100, M.-A. Lemburg wrote:
>> Phillip J. Eby wrote:
>> > At 02:35 PM 12/27/2005 +0100, Fredrik Lundh wrote:
>> >> M.-A. Lemburg wrote:
>> >>
>> can we add a opentext factory for file/codecs.open while we're at
>> it ?
>> >>> Why a new factory fun
Ronald Oussoren wrote:
> I'd prefer 'def quit(): raise SystemExit', the class above just adds
> a message for someone that accidently got stuck in a python shell. I
> don't like the idea of making quit or exit special enough to cause
> side effects without parentheses, no other function does
On 27-dec-2005, at 16:39, Fredrik Lundh wrote:
> Ronald Oussoren wrote:
>
>> Why must quit and exit be so special in the first place? They could
>> be plain functions, or even something like::
>>
>> class _QuitOrExit:
>> def __init__(self, name):
>> self.name = name
>>
>> def __repr__(self):
>> r
Hi Facundo,
On Mon, Dec 26, 2005 at 02:31:10PM -0300, Facundo Batista wrote:
> > nb_add and nb_multiply should be tried. I don't think that this would
> > break existing C or Python code, but it should probably only go in 2.5,
> > together with the patch #1390657 that relies on it.
>
> It'd be g
Phillip J. Eby wrote:
> >but that was made at a time when it wasn't clear if "open" or "file" would
> >be the preferred way to open a file. now that we've settled on the verb
> >form, I think "textopen" or "opentext" would be slightly more consistent.
>
> Sorry, I'm confused. Who settled on the
On Tuesday 27 December 2005 08:06, Fredrik Lundh wrote:
> the "trunk" link on
>
> http://www.python.org/dev/doc/
Fixed now; thanks for the reminder.
-Fred
--
Fred L. Drake, Jr.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail
Ronald Oussoren wrote:
> Why must quit and exit be so special in the first place? They could
> be plain functions, or even something like::
>
> class _QuitOrExit:
> def __init__(self, name):
> self.name = name
>
> def __repr__(self):
> return "Use %(name)s() to exit."%(self.__dict__)
>
> def __cal
At 04:37 PM 12/27/2005 +0100, Fredrik Lundh wrote:
>but that was made at a time when it wasn't clear if "open" or "file" would
>be the preferred way to open a file. now that we've settled on the verb
>form, I think "textopen" or "opentext" would be slightly more consistent.
Sorry, I'm confused.
Phillip J. Eby wrote:
> >Here's a rough draft:
> >
> > def textopen(name, mode="r", encoding=None):
> > if "U" not in mode:
> > mode += "U"
> > if encoding:
> > return codecs.open(name, mode, encoding)
> > return file(name, mode)
>
> Nice. It sho
At 04:20 PM 12/27/2005 +0100, M.-A. Lemburg wrote:
>Phillip J. Eby wrote:
> > At 02:35 PM 12/27/2005 +0100, Fredrik Lundh wrote:
> >> M.-A. Lemburg wrote:
> >>
> can we add a opentext factory for file/codecs.open while we're at it ?
> >>> Why a new factory function ? Can't we just redirect to
Phillip J. Eby wrote:
> At 02:35 PM 12/27/2005 +0100, Fredrik Lundh wrote:
>> M.-A. Lemburg wrote:
>>
can we add a opentext factory for file/codecs.open while we're at it ?
>>> Why a new factory function ? Can't we just redirect to codecs.open()
>>> in case an encoding keyword argument is pass
Hi Christian,
On Mon, Dec 26, 2005 at 01:38:37PM +0100, Christian Tismer wrote:
> I don't think your code has to decide about this. The power lies
> in the fact that you don't specify that, but just use the list
> in a different way. We do this in the PyPy implementation;
> right now it is true th
At 02:35 PM 12/27/2005 +0100, Fredrik Lundh wrote:
>M.-A. Lemburg wrote:
>
> >> can we add a opentext factory for file/codecs.open while we're at it ?
> >
> > Why a new factory function ? Can't we just redirect to codecs.open()
> > in case an encoding keyword argument is passed to open() ?!
>
>I th
On 27-dec-2005, at 14:55, Christopher Armstrong wrote:
> On 12/28/05, Reinhold Birkenfeld [EMAIL PROTECTED]> wrote:
>> Fredrik Lundh wrote:
>>> sourceforge just went off the air, so I'm posting this patch
>>> here, in order
>>> to distract you all from Christian's deque thread.
>>>
>>> this si
Fredrik Lundh wrote:
> Reinhold Birkenfeld wrote:
>
>> What is wrong with something like this:
>>
>> >>> class Quitter:
>> ... def __repr__(self): raise SystemExit
>> ...
>> >>> exit = quit = Quitter()
>
vars() # oops!
You're right.
>>> class Quitter:
... def __repr__(self):
... n = s
Fredrik Lundh wrote:
> M.-A. Lemburg wrote:
>
>>> can we add a opentext factory for file/codecs.open while we're at it ?
>> Why a new factory function ? Can't we just redirect to codecs.open()
>> in case an encoding keyword argument is passed to open() ?!
>
> I think open is overloaded enough as
On 12/28/05, Reinhold Birkenfeld <[EMAIL PROTECTED]> wrote:
> Fredrik Lundh wrote:
> > sourceforge just went off the air, so I'm posting this patch here, in order
> > to distract you all from Christian's deque thread.
> >
> > this silly little patch changes the behaviour of the interpreter so that
Reinhold Birkenfeld wrote:
> What is wrong with something like this:
>
> >>> class Quitter:
> ... def __repr__(self): raise SystemExit
> ...
> >>> exit = quit = Quitter()
>>> vars() # oops!
___
Python-Dev mailing list
Python-Dev@python.org
http:/
Fredrik Lundh wrote:
> sourceforge just went off the air, so I'm posting this patch here, in order
> to distract you all from Christian's deque thread.
>
> this silly little patch changes the behaviour of the interpreter so that
> "quit"
> and "exit" actually exits the interpreter. it does this
M.-A. Lemburg wrote:
>> can we add a opentext factory for file/codecs.open while we're at it ?
>
> Why a new factory function ? Can't we just redirect to codecs.open()
> in case an encoding keyword argument is passed to open() ?!
I think open is overloaded enough as it is. Using separate functio
Fredrik Lundh wrote:
> Aahz wrote:
>
>> class file(object)
>> | file(name[, mode[, buffering]]) -> file object
>> |
>> | Open a file. The mode can be 'r', 'w' or 'a' for reading (default),
>> [...]
>> | Note: open() is an alias for file().
>>
>> This is confusing. I suggest that we make ``op
Neal Norwitz wrote:
> And hopefully of interest to many here:
>
>http://docs.python.org/dev/results/
>
> These are the results of svn update, configure, build, test, install
> and the doc run.
the "trunk" link on
http://www.python.org/dev/doc/
still points to the old
http://www.pyt
Fredrik> whaddya think?
We're going to wind up with the same problem that spawned the atexit module:
multiple code sources wanting to fiddle with sys.excepthook step on one
another's toes. For example, I already use an excepthook in interactive
mode to try to resolve NameErrors:
% pytho
Aahz wrote:
> class file(object)
> | file(name[, mode[, buffering]]) -> file object
> |
> | Open a file. The mode can be 'r', 'w' or 'a' for reading (default),
> [...]
> | Note: open() is an alias for file().
>
> This is confusing. I suggest that we make ``open()`` a factory function
> right
sourceforge just went off the air, so I'm posting this patch here, in order
to distract you all from Christian's deque thread.
this silly little patch changes the behaviour of the interpreter so that "quit"
and "exit" actually exits the interpreter. it does this by installing a custom
excepthook
69 matches
Mail list logo
