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 now.
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:
%
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
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 ``open()`` a factory
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 functions
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 by
Reinhold Birkenfeld wrote:
What is wrong with something like this:
class Quitter:
... def __repr__(self): raise SystemExit
...
exit = quit = Quitter()
vars() # oops!
/F
___
Python-Dev mailing list
Python-Dev@python.org
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
quit
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 it is.
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 =
On 27-dec-2005, at 14:55, Christopher Armstrong wrote:
On 12/28/05, Reinhold Birkenfeld 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.
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 think open is
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 that
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 passed to open()
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 codecs.open()
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 should probably also check
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. Who
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 __call__(self):
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. fdrake at acm.org
___
Python-Dev mailing list
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 verb form? Are
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 good to
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):
return Use
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 function ? Can't we just
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-way branch,
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 the Unicode rules and
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 program.
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
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() which
breaks lines according to
Martin So if they do
quit
function quit at 0xb7d96294
Martin they are just as confused as if they got a name error.
Probably more so... wink
Skip
___
Python-Dev mailing list
Python-Dev@python.org
[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 Python
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
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
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 something
--- 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 gymnastics.
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 that
[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 probably be
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
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.
Beside, it
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
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 because
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 XP and
it doesn't
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
built-in function exit
which may be enough of a clue
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.
^Z
python
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. Please
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 tool
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.
/F
-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 'Type exit() to exit Python.'
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
about
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
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
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
[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 then
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 current
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 me
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't say
--- 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 with
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 it, though,
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, exit]
69 matches
Mail list logo
