Re: [Python-Dev] Last-minute curses patch
Martin v. Löwis wrote: > Walter Dörwald wrote: >> I have a small patch http://bugs.python.org/1506645 that adds >> resizeterm() and resize_term() to the curses module. Can this still go >> in for beta1? I'm not sure, if it needs some additional configure magic. > > It can go into beta1 until the beta1 code freeze is announced. Great! > It does need a configure test, though. Unfortunately I have no idea how this whole configure business works! Servus, Walter ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Switch statement
Raymond Hettinger wrote: >>> The optimisation of the if-elif case would then simply be to say that the >>> compiler can recognise if-elif chains like the one above where the RHS >>> of the comparisons are all hashable literals and collapse them to switch >>> statements. >>> >> >> Right (constants are usually hashable :-). >> > > The LHS is more challenging. Given: > > if x == 1: p_one() > elif x == 2: p_two() > elif x == 3: p_three() > else: p_catchall() > > There is no guarantee that x is hashable. For example: > > class X: > def __init__(self, value): > self.value = value > def __cmp__(self, y): > return self.value == y > x = X(2) That's a good point. The PEP already addresses this by retricting the type of x to a few builtin immutable and hashable types: ...the switching variable is one of the builtin immutable types: int, float, string, unicode, etc. (not subtypes, since it's not clear whether these are still immutable or not). -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jun 16 2006) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Switch statement
Greg Ewing wrote: > M.-A. Lemburg wrote: > >> My personal favorite is making the compiler >> smarter to detect the mentioned if-elif-else scheme >> and generate code which uses a lookup table for >> implementing fast branching. > > But then the values need to be actual compile-time > constants, precluding the use of symbolic names, > values precomputed a run time, etc. Good point. > A new statement would allow us to simply document > that the case values are *assumed* constant, and > then the implementation could cache them in a dict > or whatever. That would a very well hidden assignment of a "constantness" property to a symbol or expression. We'd also run into the problem of not knowing when to evaluate those case expressions, e.g. at function compile time, at run-time when first entering the switch statement, etc. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jun 16 2006) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pre-PEP: Allow Empty Subscript List Without Parentheses
> But only if it makes sense. I still think there are some > severe conceptual difficulties with 0D arrays. One is > the question of how many items it contains. With 1 or > more dimensions, you can talk about its size along any > chosen dimension. But with 0 dimensions there's no size > to measure. Who's to say a 0D array has a size of 1, then? > Part of my brain keeps saying it should be 0 -- i.e. > it contains nothing at all! For what it's worth (probably little), I'm fairly sure that if you were to ask the question of a bunch of mathematicians you'd get absolute unanimity on a 0-D array containing exactly one element, indexed by the (unique) empty sequence. You'd probably also get absolute unanimous puzzlement as to why anyone other than mathematicians should care. I'd say there are "conceptual difficulties" in the sense that the concept is difficult to get one's head around, not in the sense that there's any real doubt what the Right Answer is. For anyone unconvinced, it may or may not be helpful to meditate on the fact that **0 is 1, and that an empty product is conventionally defined to be 1. None of the above is intended to constitute argument for or against Noam's proposed change to Python. Python isn't primarily a language for mathematicians, and so much the better for Python. -- Gareth McCaughan (unashamed pure mathematician, at least by training and temperament) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Bug in stringobject?
In string_replace, there is
if (PyString_Check(from)) {
/* Can this be made a '!check' after the Unicode check? */
}
#ifdef Py_USING_UNICODE
if (PyUnicode_Check(from))
return PyUnicode_Replace((PyObject *)self,
from, to, count);
#endif
else if (PyObject_AsCharBuffer(from, &tmp_s, &tmp_len))
return NULL;
[the same check with "to"]
return (PyObject *)replace((PyStringObject *) self,
(PyStringObject *) from,
(PyStringObject *) to, count);
Can this be correct if from or to isn't a string object, but a
char buffer compatible object?
Georg
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bug in stringobject?
Georg Brandl wrote:
> In string_replace, there is
>
> if (PyString_Check(from)) {
> /* Can this be made a '!check' after the Unicode check? */
> }
> #ifdef Py_USING_UNICODE
> if (PyUnicode_Check(from))
> return PyUnicode_Replace((PyObject *)self,
>from, to, count);
> #endif
> else if (PyObject_AsCharBuffer(from, &tmp_s, &tmp_len))
> return NULL;
>
> [the same check with "to"]
>
> return (PyObject *)replace((PyStringObject *) self,
> (PyStringObject *) from,
> (PyStringObject *) to, count);
>
>
> Can this be correct if from or to isn't a string object, but a
> char buffer compatible object?
Certainly not :-)
Also note that tmp_s and tmp_len are no longer used in the
function.
It appears as if there's some code missing from the function
(and that there's no unit which actually does a string
replace with non-string objects).
Since replace() only works on string objects, it appears
as if a temporary string object would have to be created.
However, this would involve an unnecessary allocation
and copy process... it appears as if the refactoring
during the NFS sprint left out that case.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Jun 16 2006)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free !
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bug in stringobject?
M.-A. Lemburg wrote: > Since replace() only works on string objects, it appears > as if a temporary string object would have to be created. > However, this would involve an unnecessary allocation > and copy process... it appears as if the refactoring > during the NFS sprint left out that case. what's the beta 1 status ? fixing this should be trivial, but I don't have any cycles to spare today. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] unicode imports
Greetings! Although python has had full unicode support for filenames for a long time on selected platforms (e.g. Windows), there is one glaring deficiency: It cannot import from paths containing unicode. I´ve tried creating folders with chinese characters and adding them to path, to no avail. The standard install path in chinese distributions can be with a non-ANSI path, and installing an embedded python application there will break it. At the moment this is hindering the installation of EVE on Chinese internet-cafés. A cursory glance at import.c shows that the import mechanism is fairly complicated, and riddled with "char *path" thingies, and manual string arithmetic. Do you have any suggestions on a clean way to unicodify the import mechanism? A completely parallel implementation on the sys.path[i] level? Are there other platforms beside Windows that would profit from this? Cheers, Kristján ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pre-PEP: Allow Empty Subscript List Without Parentheses
Hello,
It seems to me that people don't object to my proposal, but don't find
it useful to them either.
The question is, what to do next. I guess one possibility is to raise
this discussion again in a few months, when people will be less
occupied with 2.5 beta. This is ok, although I would prefer a decision
before that, because it might affect the design of the library -
should I find a permanent workaround, or one that I know that will be
removed in the future.
If you do want to continue the discussion to reach a decision, please
do. You can say that if nobody else on python-dev is interested, it
shouldn't be implemented. You can examine my use case, say if you
think it's reasonable, and suggest alternative solutions - or say that
you see how allowing empty subscript list solves it elegantly (yes!)
My point is, I don't want this discussion to naturally die because
nobody is interested, since I am interested. So please say what you
think should happen to it, so we can reach a conclusion.
Now, if a the discussion is to continue, Nick proposed an alternative:
2006/6/11, Nick Coghlan <[EMAIL PROTECTED]>:
> For your specific use cases, though, I'd be inclined to tweak the API a bit,
> and switch to using attributes for the single-valued data:
>
> tax_rates.income_tax = 0.18
It's probably ok, although I would prefer not having to artificially
group scalars just to make them attributes of something. I would
prefer remaining with one object, and having something like
income_tax.setvalue(), or even income_tax.value.
> Although the income tax rate should actually depend on the current financial
> year, since it can change over time as the government increases taxes ;)
But that's exactly why I prefer writing simply "income_tax[] = 0.18"
when it's a constant, which is completely analogous to
"income_tax[2005] = 0.17; income_tax[2006] = 0.18" when it depends on
something.
By the way, another thing about consistency: A friend of mine brought
the point that there isn't another example of forbidden empty brackets
- [], {}, (), x() are all allowed.
And about the other thing Nick said:
> I guess I'm really only -0 on the idea of x[] invoking x.__getitem__(), and
> allowing the class to decide whether or not to define a default value for the
> subscript. I wouldn't implement it myself, but I wouldn't object strenuously
> if Guido decided it was OK :)
I would prefer an empty tuple, since invoking __getitem__ with no
arguments would be a special case: for all other possible subscript
lists, exactly one argument is passed to __getitem__. This leaves us
with one special case: a subscript list with one item and without a
trailing comma results in __getitem__ not getting a tuple, where in
all other cases it does get a tuple. This works exactly like
parentheses: they don't mean a tuple only when there's one item inside
them and no trailing comma.
Good bye,
Noam
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pre-PEP: Allow Empty Subscript List Without Parentheses
2006/6/16, Gareth McCaughan <[EMAIL PROTECTED]>: > None of the above is intended to constitute argument for > or against Noam's proposed change to Python. Python isn't > primarily a language for mathematicians, and so much the > better for Python. > Thanks for your explanation of mathematical zero dimensional array! I just wanted to say that I really got to this just from trying to make a *computer program* as simple as possible - from what I know now, with empty subscript lists not allowed, my library will have more lines of code, will have more details of interface, and will require longer code to operate it. I'm not saying that not changing it will be terrible - I'm just saying that if changing something makes other things simpler AND goes along with mathematical intuition, it might be the right thing to do... Noam ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] unicode imports
Kristján V. Jónsson wrote: > A cursory glance at import.c shows that the import mechanism is fairly > complicated, and riddled with "char *path" thingies, and manual string > arithmetic. Do you have any suggestions on a clean way to unicodify the > import mechanism? Can you install a PEP 302 path hook and importer/loader that can handle path entries that are Unicode strings? (I think this would end up being the parallel implementation you were talking about, though) If the code that traverses sys.path and sys.path_hooks is itself unicode-unaware (I don't remember if it is or isn't), then you might be able to trick it by poking a Unicode-savvy importer directly into the path_importer_cache for affected Unicode paths. One issue is that the package and file names still have to be valid Python identifiers, which means ASCII. Unicode would be, at best, permitted only in the path entries. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] unicode imports
At 01:29 AM 6/17/2006 +1000, Nick Coghlan wrote: >Kristján V. Jónsson wrote: > > A cursory glance at import.c shows that the import mechanism is fairly > > complicated, and riddled with "char *path" thingies, and manual string > > arithmetic. Do you have any suggestions on a clean way to unicodify the > > import mechanism? > >Can you install a PEP 302 path hook and importer/loader that can handle path >entries that are Unicode strings? (I think this would end up being the >parallel implementation you were talking about, though) > >If the code that traverses sys.path and sys.path_hooks is itself >unicode-unaware (I don't remember if it is or isn't), then you might be able >to trick it by poking a Unicode-savvy importer directly into the >path_importer_cache for affected Unicode paths. Actually, you would want to put it in sys.path_hooks, and then instances would be placed in path_importer_cache automatically. If you are adding it to the path_hooks after the fact, you should simply clear the path_importer_cache. Simply poking stuff into the path_importer_cache is not a recommended approach. >One issue is that the package and file names still have to be valid Python >identifiers, which means ASCII. Unicode would be, at best, permitted only in >the path entries. If I understand the problem correctly, the issue is that if you install Python itself to a Unicode directory, you'll be unable to import anything from the standard library. This isn't about module names, it's about the places on the path where that stuff goes. However, if the issue is that the program works, but it puts unicode entries on sys.path, I would suggest simply encoding them to strings using the platform-appropriate codec. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pre-PEP: Allow Empty Subscript List Without Parentheses
"Noam Raphael" <[EMAIL PROTECTED]> wrote: > > 2006/6/16, Gareth McCaughan <[EMAIL PROTECTED]>: > > None of the above is intended to constitute argument for > > or against Noam's proposed change to Python. Python isn't > > primarily a language for mathematicians, and so much the > > better for Python. > > > Thanks for your explanation of mathematical zero dimensional array! I > just wanted to say that I really got to this just from trying to make > a *computer program* as simple as possible - from what I know now, > with empty subscript lists not allowed, my library will have more > lines of code, will have more details of interface, and will require > longer code to operate it. I'm not saying that not changing it will be > terrible - I'm just saying that if changing something makes other > things simpler AND goes along with mathematical intuition, it might be > the right thing to do... I'm not a mathematician, and I don't really work with arrays of any dimensionality, so the need for 0-D subscripting via arr[] while being cute, isn't compelling to my uses for Python. Now, I appreciate the desire to reduce code length and complexity, but from what I understand, the ultimate result of such a change to your code would be to go from: arr[()] to: arr[] I don't see how this can reduce lines of code in implementation or use. At most it is a two characters per use, and a change in documentation (specifying how you subscript 0-D arrays). If you can show an example where actual code line count is reduced with this change, I can't guarantee that I would get behind this proposal in a few months (if the conversation starts up again), but it may make me feel less that your proposal is essentially about aesthetics. - Josiah ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] unicode imports
On Jun 16, 2006, at 9:02 AM, Phillip J. Eby wrote: > At 01:29 AM 6/17/2006 +1000, Nick Coghlan wrote: >> Kristján V. Jónsson wrote: >>> A cursory glance at import.c shows that the import mechanism is >>> fairly >>> complicated, and riddled with "char *path" thingies, and manual >>> string >>> arithmetic. Do you have any suggestions on a clean way to >>> unicodify the >>> import mechanism? >> >> Can you install a PEP 302 path hook and importer/loader that can >> handle path >> entries that are Unicode strings? (I think this would end up being >> the >> parallel implementation you were talking about, though) >> >> If the code that traverses sys.path and sys.path_hooks is itself >> unicode-unaware (I don't remember if it is or isn't), then you >> might be able >> to trick it by poking a Unicode-savvy importer directly into the >> path_importer_cache for affected Unicode paths. > > Actually, you would want to put it in sys.path_hooks, and then > instances > would be placed in path_importer_cache automatically. If you are > adding it > to the path_hooks after the fact, you should simply clear the > path_importer_cache. Simply poking stuff into the > path_importer_cache is > not a recommended approach. > > >> One issue is that the package and file names still have to be >> valid Python >> identifiers, which means ASCII. Unicode would be, at best, >> permitted only in >> the path entries. > > If I understand the problem correctly, the issue is that if you > install > Python itself to a Unicode directory, you'll be unable to import > anything > from the standard library. This isn't about module names, it's > about the > places on the path where that stuff goes. There's a similar issue in that if sys.prefix contains a colon, Python is also busted: http://python.org/sf/1507224 Of course, that's not a Windows issue, but it is everywhere else. The offending code in that case is Modules/getpath.c, which probably also has to change in order to make unicode directories work on Win32 (though I think there may be a separate win32 implementation of getpath). -bob ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Python 2.4 extensions require VC 7.1?
A colleague recently posted this message: > I'm trying to build a Python extension, and Python 2.4 insists on the MS > Visual C++ compiler version 7.1, which is included with the MS VC++ 2003 > toolkit. This toolkit is no longer available for download from > Microsoft (superseded by the 2005 version), so I'm stuck. This seems sub-optimal. I'm afraid I don't follow the Windows track closely; has this been fixed for 2.5, or should it be reported as a bug? Bill ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: subprocess.Popen(.... stdout=IGNORE, ...)
On Tue, 13 Jun 2006, Martin Blais wrote:
Hi all. Now let's see if I remember something about my module...
> In the subprocess module, by default the files handles in the child
> are inherited from the parent. To ignore a child's output, I can use
> the stdout or stderr options to send the output to a pipe::
>
>p = Popen(command, stdout=PIPE, stderr=PIPE)
>
> However, this is sensitive to the buffer deadlock problem, where for
> example the buffer for stderr might become full and a deadlock occurs
> because the child is blocked on writing to stderr and the parent is
> blocked on reading from stdout or waiting for the child to finish.
>
> For example, using this command will cause deadlock::
>
>call('cat /boot/vmlinuz'.split(), stdout=PIPE, stderr=PIPE)
Yes, the call convenience function is basically for the case when you are
not interested in redirection.
> Popen.communicate() implements a solution using either select() or
> multiple threads (under Windows) to read from the pipes, and returns
> the strings as a result. It works out like this::
>
>p = Popen(command, stdout=PIPE, stderr=PIPE)
>output, errors = p.communicate()
>if p.returncode != 0:
> ?
>
> Now, as a user of the subprocess module, sometimes I just want to
> call some child process and simply ignore its output, and to do so I
> am forced to use communicate() as above and wastefully capture and
> ignore the strings. This is actually quite a common use case. "Just
> run something, and check the return code".
Yes, this is a common case, and using communicate() is indeed overkill and
wasteful.
> Right now, in order to do
> this without polluting the parent's output, you cannot use the call()
> convenience (or is there another way?).
>
> A workaround that works under UNIX is to do this::
>
>FNULL = open('/dev/null', 'w')
>returncode = call(command, stdout=FNULL, stderr=FNULL)
Yes, this works. You can also do:
returncode = subprocess.call(command, stdout=open('/dev/null', 'w'),
stderr=subprocess.STDOUT)
> Some feedback requested, I'd like to know what you think:
>
> 1. Would it not be nice to add a IGNORE constant to subprocess.py
>that would do this automatically?, i.e. ::
>
> returncode = call(command, stdout=IGNORE, stderr=IGNORE)
>
>Rather than capture and accumulate the output, it would find an
>appropriate OS-specific way to ignore the output (the /dev/null file
>above works well under UNIX, how would you do this under Windows?
>I'm sure we can find something.)
I have a vague feeling of that this has been discussed before, but I
cannot find a tracker for this. I guess an IGNORE constant would be nice.
Using open('/dev/null', 'w') is only a few more characters to type, but as
you say, it's not platform independent.
So, feel free to submit a patch or a Feature Request Tracker.
> 2. call() should be modified to not be sensitive to the deadlock
>problem, since its interface provides no way to return the
>contents of the output. The IGNORE value provides a possible
>solution for this.
How do you suggest the call() should be modified? I'm not really sure it
can do more without being more complicated. Being simple is the main
purpose of call().
> 3. With the /dev/null file solution, the following code actually
>works without deadlock, because stderr is never blocked on writing
>to /dev/null::
>
> p = Popen(command, stdout=PIPE, stderr=IGNORE)
> text = p.stdout.read()
> retcode = p.wait()
>
>Any idea how this idiom could be supported using a more portable
>solution (i.e. how would I make this idiom under Windows, is there
>some equivalent to /dev/null)?
Yes, as Terry Reedy points out, NUL: can be used.
Regards,
/Peter Åstrand <[EMAIL PROTECTED]>
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: subprocess.Popen(.... stdout=IGNORE, ...)
There is a related bit of functionality for subprocess that would allow
for asynchronous handling of IO to/from the called subprocess. It has
been implemented as a recipe [1], but requires the use of additional
pywin32 functionality on Windows. As was the case for the original
subprocess module, in order to get the proper functionality on Windows,
we may need to include additional features from pywin32 into the
_subprocess.c driver, or alternatively, convert all _subprocess.c bits
into ctypes calls.
If the inclusion of additional code into _subprocess.c or the use of
ctypes is undesireable, this feature could require the *user* to install
pywin32 on Windows, which would be unfortunate, but perfectly reasonable.
With an asynchronous handler for the subprocess module, a user could
ignore or process output from a subprocess as desired or necessary.
- Josiah
[1] http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/440554
Peter Astrand <[EMAIL PROTECTED]> wrote:
>
> On Tue, 13 Jun 2006, Martin Blais wrote:
>
> Hi all. Now let's see if I remember something about my module...
>
>
> > In the subprocess module, by default the files handles in the child
> > are inherited from the parent. To ignore a child's output, I can use
> > the stdout or stderr options to send the output to a pipe::
> >
> >p = Popen(command, stdout=PIPE, stderr=PIPE)
> >
> > However, this is sensitive to the buffer deadlock problem, where for
> > example the buffer for stderr might become full and a deadlock occurs
> > because the child is blocked on writing to stderr and the parent is
> > blocked on reading from stdout or waiting for the child to finish.
> >
> > For example, using this command will cause deadlock::
> >
> >call('cat /boot/vmlinuz'.split(), stdout=PIPE, stderr=PIPE)
>
> Yes, the call convenience function is basically for the case when you are
> not interested in redirection.
>
>
> > Popen.communicate() implements a solution using either select() or
> > multiple threads (under Windows) to read from the pipes, and returns
> > the strings as a result. It works out like this::
> >
> >p = Popen(command, stdout=PIPE, stderr=PIPE)
> >output, errors = p.communicate()
> >if p.returncode != 0:
> > ?
> >
> > Now, as a user of the subprocess module, sometimes I just want to
> > call some child process and simply ignore its output, and to do so I
> > am forced to use communicate() as above and wastefully capture and
> > ignore the strings. This is actually quite a common use case. "Just
> > run something, and check the return code".
>
> Yes, this is a common case, and using communicate() is indeed overkill and
> wasteful.
>
>
> > Right now, in order to do
> > this without polluting the parent's output, you cannot use the call()
> > convenience (or is there another way?).
> >
> > A workaround that works under UNIX is to do this::
> >
> >FNULL = open('/dev/null', 'w')
> >returncode = call(command, stdout=FNULL, stderr=FNULL)
>
> Yes, this works. You can also do:
>
> returncode = subprocess.call(command, stdout=open('/dev/null', 'w'),
> stderr=subprocess.STDOUT)
>
>
> > Some feedback requested, I'd like to know what you think:
> >
> > 1. Would it not be nice to add a IGNORE constant to subprocess.py
> >that would do this automatically?, i.e. ::
> >
> > returncode = call(command, stdout=IGNORE, stderr=IGNORE)
> >
> >Rather than capture and accumulate the output, it would find an
> >appropriate OS-specific way to ignore the output (the /dev/null file
> >above works well under UNIX, how would you do this under Windows?
> >I'm sure we can find something.)
>
> I have a vague feeling of that this has been discussed before, but I
> cannot find a tracker for this. I guess an IGNORE constant would be nice.
> Using open('/dev/null', 'w') is only a few more characters to type, but as
> you say, it's not platform independent.
>
> So, feel free to submit a patch or a Feature Request Tracker.
>
>
> > 2. call() should be modified to not be sensitive to the deadlock
> >problem, since its interface provides no way to return the
> >contents of the output. The IGNORE value provides a possible
> >solution for this.
>
> How do you suggest the call() should be modified? I'm not really sure it
> can do more without being more complicated. Being simple is the main
> purpose of call().
>
>
> > 3. With the /dev/null file solution, the following code actually
> >works without deadlock, because stderr is never blocked on writing
> >to /dev/null::
> >
> > p = Popen(command, stdout=PIPE, stderr=IGNORE)
> > text = p.stdout.read()
> > retcode = p.wait()
> >
> >Any idea how this idiom could be supported using a more portable
> >solution (i.e. how would I make this idiom under Windows, is there
> >some equivalent to /dev/null)?
>
> Yes, as Terry Reedy points out, NUL: can be used.
>
> Regards,
> /Peter Åstrand <[EMAIL PROTECTED]>
>
Re: [Python-Dev] Beta 1 schedule ? (Bug in stringobject?)
Fredrik Lundh wrote: > M.-A. Lemburg wrote: >> Since replace() only works on string objects, it appears >> as if a temporary string object would have to be created. >> However, this would involve an unnecessary allocation >> and copy process... it appears as if the refactoring >> during the NFS sprint left out that case. > > what's the beta 1 status ? fixing this should be trivial, but I don't have > any > cycles to spare today. Good question. PEP 356 says beta 1 was planned two days ago... http://www.python.org/dev/peps/pep-0356/ I'd also like to get the new winerror module in before beta1 is released - documentation will follow next week: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1505257&group_id=5470 Is it OK to first check in a pure Python version and then replace this with a C implementation having the same interface later on in the beta cycle ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jun 16 2006) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Last-minute curses patch
Walter Dörwald wrote: >> It can go into beta1 until the beta1 code freeze is announced. > > Great! > >> It does need a configure test, though. > > Unfortunately I have no idea how this whole configure business works! Unfortunately, this either means you have to learn it, or find somebody who does it for you. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] An obscene computed goto bytecode hack for "switch" :)
For folks contemplating what opcodes might need to be added to implement a
"switch" statement, it turns out that there is a "clever way" (i.e. a
filthy hack) to implement computed jumps in Python bytecode, using
WHY_CONTINUE and END_FINALLY.
I discovered this rather by accident, while working on my BytecodeAssembler
package: I was adding validation code to minimize the likelihood of
generating incorrect code for blocks and loops, and so I was reading
ceval.c to make sure I knew how those bytecodes worked.
And at some point it dawned on me that an END_FINALLY opcode that sees
WHY_FINALLY on top of the stack *is actually a computed goto*! It has to
be inside a SETUP_LOOP/POP_BLOCK pair, but apart from that it's quite
straightforward.
So, taking the following example code as a basis for the input:
def foo(x):
switch x:
case 1: return 42
case 2: return 'foo'
else: return 27
I created a proof-of-concept implementation that generated the following
bytecode for the function:
0 0 SETUP_LOOP 36 (to 39)
3 LOAD_CONST 1 (<...method get of dict...>)
6 LOAD_FAST0 (x)
9 CALL_FUNCTION1
12 JUMP_IF_FALSE 18 (to 33)
15 LOAD_CONST 2 (...)
18 END_FINALLY
19 LOAD_CONST 3 (42)
22 RETURN_VALUE
23 JUMP_FORWARD12 (to 38)
26 LOAD_CONST 4 ('foo')
29 RETURN_VALUE
30 JUMP_FORWARD 5 (to 38)
>> 33 POP_TOP
34 LOAD_CONST 5 (27)
37 RETURN_VALUE
>> 38 POP_BLOCK
>> 39 LOAD_CONST 0 (None)
42 RETURN_VALUE
The code begins with a SETUP_LOOP, so that our pseudo-continues will
work. As a pleasant side-effect, any BREAK_LOOP operations in any of the
suites will exit the entire switch block, jumping to offset 39 and the
function exit.
At offset 3, I load the 'get' method of the switching dictionary as a
constant -- this was simpler for my proof-of-concept, but a production
version should probably load the dictionary and then get its 'get' method,
because methods aren't marshallable and the above code therefore can't be
saved in a .pyc file. The remaining code up to offset 12 does a dictionary
lookup, defaulting to None if the value of the switch expression isn't found.
At offset 12, I check if the jump target is false, and if so I assume it's
None, and jump ahead to the "else" suite. If it's true, I load a constant
value equal to the correct value of WHY_CONTINUE for the current Python
version and fall through to the END_FINALLY. So the END_FINALLY then pops
WHY_CONTINUE and the jump target, jumping forward to the correct "case" branch.
The code that follows is then a series of "case" suites, each ending with a
JUMP_FORWARD to the POP_BLOCK that ends the "loop". In this case, however,
those jumps are never actually taken, but if execution "fell out" of any of
the cases, they would proceed to the end this way.
Anyway, the above function actually *runs* in any version of Python back to
2.3, as long as the LOAD_CONST at offset 15 uses the right value of
WHY_CONTINUE for that Python version. Older Python versions are of course
not going to have a "switch" statement, but the reason I'm excited about
this is that I've been wishing for some way to branch within a function in
order to create fast jump tables for generic functions. This is pretty
much what the doctor ordered.
One thing I'm curious about, if there are any PyPy folks listening: will
tricks like this drive PyPy or Psyco insane? :) It's more than idle
curiosity, as one of my goals for my next generic function system is that
it should generate bytecode that's usable by PyPy and Psyco for
optimization or translation purposes.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] setobject code
I would like to share a couple of observations that I made as I studied the latest setobject implementation. 1. Is there a reason not to have PySet_CheckExact, given that PyFrozenSet_CheckExact exists? Similarly, why PyAnySet_Check, but no PySet_Check or PyFrozenSet_Check? 2. Type of several data members in dict-object and dict-entry structs were recently changed to Py_ssize_t . Whatever considerations prompted the change, they should probably apply to the similar members of set-object and set-entry structs as well. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] unicode imports
Phillip J. Eby wrote: > Actually, you would want to put it in sys.path_hooks, and then instances > would be placed in path_importer_cache automatically. If you are adding > it to the path_hooks after the fact, you should simply clear the > path_importer_cache. Simply poking stuff into the path_importer_cache > is not a recommended approach. Oh, I agree - poking it in directly was a desperation measure if the path_hooks machinery didn't like Unicode either. I've since gone and looked, and you may be screwed either way - the standard import paths appear to be always put on the system path as encoded 8-bit strings, not as Unicode objects. That said, it also appears that the existing machinery *should* be able to handle non-ASCII path items, so long as 'Py_FileSystemDefaultEncoding' is set correctly. If it isn't handling it, then there's something else going wrong. Modules/getpath.c and friends don't encode the results returned by the platform APIs, so the strings in Kristján, can you provide more details on the fault you get when trying to import from the path containing the Chinese characters? Specifically: What is the actual file system path? What do sys.prefix, sys.exec_prefix and sys.path contain? What does sys.getdefaultencoding() return? What do sys.stdin.encoding, sys.stdout.encoding and sys.stderr.encoding say? What does "python -v" show? Does adding the standard lib directories manually to sys.path make any difference? Does setting PYTHONHOME to the appropriate settings make any difference? Running something like the following would be good: import sys print "Prefixes:", sys.prefix, sys.exec_prefixes print "Path:", sys.path print "Default encoding:", sys.getdefaultencoding() print "Input encoding:", sys.stdin.encoding, print "Output encodings:", sys.stdout.encoding, sys.stderr.encoding try: import string # Make python -v do something interesting except ImportError: print "Could not find string module" sys.path.append(u"stdlib directory name") try: import string # Make python -v do something interesting except ImportError: print "Could not find string module" -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] unicode imports
Bob Ippolito wrote:
> There's a similar issue in that if sys.prefix contains a colon, Python
> is also busted:
> http://python.org/sf/1507224
>
> Of course, that's not a Windows issue, but it is everywhere else. The
> offending code in that case is Modules/getpath.c,
Since it has to do with the definition of Py_GetPath as returning a single
string that is really a DELIM separated list of strings, where DELIM is
defined by the current platform (';' on Windows, ':' everywhere else), this
seems more like a platform problem than a Python problem, though - you can't
have directories containing a colon as an entry in PATH or PYTHONPATH either.
It's not really Python's fault that the platform defines a legal filename
character as the delimiter for path entries.
The only real alternative I can see is to normalise Py_GetPath to always
return a ';' delimited list of strings, regardless of platform, and update
PySys_SetPath accordingly. That'd cause potential compatibility problems for
embedded interpreters, though.
I guess we could create a Py_GetPathEx and a PySys_SetPathEx that accepted the
delimeters as arguments, and change the call in pythonrun.c from:
PySys_SetPath(Py_GetPath())
to:
PySys_SetPathEx(Py_GetPathEx(';'), ';')
(still an incompatible change, but an easier to manage one since you can
easily provide different behavior for earlier versions of Python)
> which probably also
> has to change in order to make unicode directories work on Win32 (though
> I think there may be a separate win32 implementation of getpath).
There is - PC/getpathp.c
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http://www.boredomandlaziness.org
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] unicode imports
Kristján V. Jónsson: > Although python has had full unicode support for filenames for a long time > on selected platforms (e.g. Windows), there is one glaring deficiency: It > cannot import from paths containing unicode. I´ve tried creating folders > with chinese characters and adding them to path, to no avail. > The standard install path in chinese distributions can be with a non-ANSI > path, and installing an embedded python application there will break it. It should be unusual for a Chinese installation to use an install path that can not be represented in MBCS. Try encoding the install directory into MBCS before adding it to sys.path. Neil ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Beta 1 schedule ? (Bug in stringobject?)
On 6/16/06, M.-A. Lemburg <[EMAIL PROTECTED]> wrote: > Fredrik Lundh wrote: > > > > what's the beta 1 status ? fixing this should be trivial, but I don't have > > any > > cycles to spare today. > > Good question. PEP 356 says beta 1 was planned two days > ago... > > http://www.python.org/dev/peps/pep-0356/ beta 1 won't be released until the tests pass consistently. That hasn't happened much this week. I updated the PEP's schedule. Hopefully we can release early next week. This means the code freeze is likely to happen as early as Sunday (more likely Monday or Tuesday). http://mail.python.org/pipermail/python-checkins/2006-June/054104.html > I'd also like to get the new winerror module in before > beta1 is released - documentation will follow next week: > > https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1505257&group_id=5470 > > Is it OK to first check in a pure Python version and then > replace this with a C implementation having the same interface > later on in the beta cycle ? My answer is no. We've had too much breakage. There are so many things already in 2.5. We really don't need one more thing to break. There will be a 2.6. winerror has limited impact. At this point, I'd rather not see any checkins except to fix something that's broken. tests, doc, and bugfixes. I seem to recall a bunch of checkins recently that didn't have a test. n ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.4 extensions require VC 7.1?
Bill Janssen <[EMAIL PROTECTED]> wrote: >> I'm trying to build a Python extension, and Python 2.4 insists on >> the MS >> Visual C++ compiler version 7.1, which is included with the MS VC++ >> 2003 >> toolkit. This toolkit is no longer available for download from >> Microsoft (superseded by the 2005 version), so I'm stuck. > > This seems sub-optimal. I'm afraid I don't follow the Windows track > closely; has this been fixed for 2.5, or should it be reported as a > bug? It was discussed before, and the agreement was to use VS 2003 for another cycle (i.e. 2.5). But the fact that VS 2003 is no longer available for download is an important fact, and we might want to rediscuss the issue. Giovanni Bajo ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.4 extensions require VC 7.1?
Giovanni Bajo wrote: > It was discussed before, and the agreement was to use VS 2003 for another > cycle > (i.e. 2.5). But the fact that VS 2003 is no longer available for download is > an > important fact, and we might want to rediscuss the issue. it's still available in the .net sdk packages (see comp.lang.python), and it's still available for MSDN subscribers. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] unicode imports
On Jun 16, 2006, at 9:44 PM, Nick Coghlan wrote:
> Bob Ippolito wrote:
>> There's a similar issue in that if sys.prefix contains a colon,
>> Python is also busted:
>> http://python.org/sf/1507224
>> Of course, that's not a Windows issue, but it is everywhere else.
>> The offending code in that case is Modules/getpath.c,
>
> Since it has to do with the definition of Py_GetPath as returning a
> single string that is really a DELIM separated list of strings,
> where DELIM is defined by the current platform (';' on Windows, ':'
> everywhere else), this seems more like a platform problem than a
> Python problem, though - you can't have directories containing a
> colon as an entry in PATH or PYTHONPATH either. It's not really
> Python's fault that the platform defines a legal filename character
> as the delimiter for path entries.
>
> The only real alternative I can see is to normalise Py_GetPath to
> always return a ';' delimited list of strings, regardless of
> platform, and update PySys_SetPath accordingly. That'd cause
> potential compatibility problems for embedded interpreters, though.
>
> I guess we could create a Py_GetPathEx and a PySys_SetPathEx that
> accepted the delimeters as arguments, and change the call in
> pythonrun.c from:
>
> PySys_SetPath(Py_GetPath())
>
> to:
>
> PySys_SetPathEx(Py_GetPathEx(';'), ';')
>
> (still an incompatible change, but an easier to manage one since
> you can easily provide different behavior for earlier versions of
> Python)
No, that doesn't fix anything at all. The right solution is not to
provide for a different delimiter, but allow for a list (probably too
early for PyObject* though) or array of some kind (e.g. int argc,
char **argv).
-bob
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
