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
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
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
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 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
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:
> 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
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:/
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
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
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
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
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
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
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
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:
> >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: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.
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
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
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
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
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
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
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
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
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 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
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
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
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:
[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 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
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
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
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
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
--- "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
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
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):
--- 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
[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
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
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
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
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
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.
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
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
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
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
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.
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 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
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
>
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.
_
-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
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
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
> 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
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
[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
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
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
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'
--- 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
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
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
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,
69 matches
Mail list logo
