Re: [Python-Dev] io.BufferedReader.peek() Behaviour in python3.1

[Nick Coghlan]

Cameron Simpson wrote:
> On 13Jun2009 12:24, Nick Coghlan  wrote:
> | I would phrase this suggestion as users having a reasonable expectation
> | that the following invariant should hold for a buffered stream:
> | 
> |   f.peek(n) == f.read(n)
> | 
> | Since the latter method will perform as many reads of the underlying
> | stream as necessary to reach the requested number of bytes (or EOF),
> | then so should the former.
> 
> I disagree. If that were that case, why have peek() at all? I realise
> that it doesn't move the logical position, but it does mean that
> peek(huge_number) imposes a requirement to grow the stream buffer
> arbitrarily.
> 
> A peek that does at most one raw read has the advantage that it can pick up
> data outside the buffer but lurking in the OS buffer, yet to be obtained.
> Those data are free, if they're present. (Of course, if they're absent
> peek() wil still block).

Note my suggestion later that if the above invariant were to be adopted
then a peek1() method should be added to parallel read1().

However, from what Benjamin has said, a more likely invariant is going
to be:

  preview = f.peek(n)
  f.read(n).startswith(preview)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
---
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status of 2.7 and 3.2

[Eric Pruitt]

I am in the process of implementing a number of often requested features and
proposed patches in the subprocess module for my Google Summer of Code 2009
project. For information on my progress, check out my blog located at *
http://subdev.blogspot.com/* . Any comments and
suggestions are greatly appreciated.

> Just my 0.02 cents, but struggling with all warts of 2.5 subprocessing
> > in Windows I would vote for more time for stabilizating things - not
> > adding new features. Long awaited subprocess as replacement for
> > os.popen() AFAIK is still incapable to asynchronously communicate with
> > spawned processes on Windows. I would call this feature as critical
> > even on 2.6  As a release testcase - try porting pyexpect module to
> > this platform. Absence of native curses/console/readline module also
> > makes Python one-way unix shell language while many users expect it to
> > be crossplatform.
>
> I am not quite sure whether you are for new features or not. Your
> first sentence ("vote for ... not adding new features") seems to
> suggest that you would not like to see new features, and your last
> sentence ("absence of native curses/console/readline module")
> suggests that you *do* want to see new features (namely, a native
> curses module, and a native readline module).
>
> Which one is it?
>
> Regards,
> Martin
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status of 2.7 and 3.2

[Lennart Regebro]

2009/6/7 Stephen J. Turnbull :
> Python's 2.x/py3k division is a tour de force; I still can't believe
> my eyes that you've pulled it off.

Well, It's not pulled off until Python 3 has surpassed Python 2 in
usage. That's still a long way away. I'm not familiar with the other
examples except Zope 3, which is a completely different thing, so it
may very well be that Python did it way better. But still, it's not
pulled off yet.

-- 
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status of 2.7 and 3.2

[Stephen J. Turnbull]

Lennart Regebro writes:
 > 2009/6/7 Stephen J. Turnbull :
 > > Python's 2.x/py3k division is a tour de force; I still can't believe
 > > my eyes that you've pulled it off.
 > 
 > Well, It's not pulled off until Python 3 has surpassed Python 2 in
 > usage.

I'm referring only to the management of the dual-trunk workflow, not
to whether Python3 will be the preferred path for the future.  That
workflow has its problems, but still it seems very successful in
keeping what needs to be synced, synced, and what needs to be
different, different.

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] io.BufferedReader.peek() Behaviour in python3.1

[Antoine Pitrou]

Nick Coghlan  gmail.com> writes:
> 
> Since the latter method will perform as many reads of the underlying
> stream as necessary to reach the requested number of bytes (or EOF),
> then so should the former.

How do you propose to implement this while staying compatible with
1) unseekable raw streams
2) the expectation that peek() doesn't advance the logical file pointer?

> Note that the current behaviour I get from Python 3.1 is for it to
> return the *entire* buffer, no matter what number I pass to it:
> 
[...]
> 
> That's an outright bug - I've promoted an existing issue about this [1]
> to a release blocker and sent it to Benjamin to have another look at.

The original docstring for peek() says:

"""Returns buffered bytes without advancing the position.

The argument indicates a desired minimal number of bytes; we
do at most one raw read to satisfy it.  We never return more
than self.buffer_size.
"""

In that light, I'm not sure it's a bug -- although it can certainly look
unexpected at first sight.

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] io.BufferedReader.peek() Behaviour in python3.1

[Antoine Pitrou]

Frederick Reeve  solace.info> writes:
> 
> peek(n):
> If n is less than 0, None, or not set; return buffer contents with out
> advancing stream position. If the buffer is empty read a full chunk and
> return the buffer.  Otherwise return exactly n bytes up to _chunk
> size_(not contents) with out advancing the stream position.  If the
> buffer contents is less than n, buffer an additional chunk from the
> "raw" stream before hand.  If EOF is encountered during any raw read
> then return as much as we can up to n. (maybe I should write that in
> code form??)

This proposal looks reasonable to me. Please note that it's too late for 3.1
anyway - we're in release candidate phase. Once you have a patch, you can post
it on the bug tracker.

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status of 2.7 and 3.2

[Antoine Pitrou]

Eric Pruitt  gmail.com> writes:
> 
> I am in the process of implementing a 
> number of often requested features and proposed patches in the subprocess 
> module for my Google Summer of Code 2009 project. For information on 
> my progress, check out my blog located at http://subdev.blogspot.com/.

Please note there's already a Mercurial mirror of the Python trunk:
http://code.python.org/hg/trunk/

(I'm replying here since your blog disallows anonymous comments)


Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Avoiding file descriptors leakage in subprocess.Popen()

[Facundo Batista]

On Fri, Jun 12, 2009 at 9:06 PM, Christian Heimes wrote:

> How about a nice 'n shiny context wrapper for the pipe:

I'll do this!

Thank you for the suggestion!

BTW, as this is a good way of avoiding the FD leakage, should this
context wrapper for pipe() be in the stdlib?

Regards,

-- 
.Facundo

Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Iterator version of contextlib.nested

[Hagen Fürstenau]

> The semantic change actually needed to make nested() more equivalent to
> the multi-with statement is for it to accept zero-argument callables
> that create context managers as arguments rather than pre-created
> context managers.

It seems to me that both passing callables which return managers and
passing a generator which yields managers achieve about the same thing.
Are you proposing the former just to avoid introducing a new interface?

> Rather than changing the name of the function, this could be done by
> inspecting the first argument for an "__enter__" method. If it has one,
> use the old semantics (and issue a DeprecationWarning as in 3.1).
> Otherwise, use the proposed new semantics.

I guess this is much too late for 3.1, but could we then at least
un-deprecate "contextlib.nested" for now? As it is, you get a
DeprecationWarning for something like

with contextlib.nested(*my_managers):

without any good way to get rid of it.

- Hagen
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] [RELEASED] Python 3.1 Release Candidate 2

[Benjamin Peterson]

On behalf of the Python development team, I'm happy to announce the second
release candidate of Python 3.1.

Python 3.1 focuses on the stabilization and optimization of the features and
changes that Python 3.0 introduced.  For example, the new I/O system has been
rewritten in C for speed.  File system APIs that use unicode strings now handle
paths with undecodable bytes in them. Other features include an ordered
dictionary implementation, a condensed syntax for nested with statements, and
support for ttk Tile in Tkinter.  For a more extensive list of changes in 3.1,
see http://doc.python.org/dev/py3k/whatsnew/3.1.html or Misc/NEWS in the Python
distribution.

This is a release candidate, and as such, we do not recommend use in production
environments.  However, please take this opportunity to test the release with
your libraries or applications.  This will hopefully discover bugs before the
final release and allow you to determine how changes in 3.1 might impact you.
If you find things broken or incorrect, please submit a bug report at

 http://bugs.python.org

For more information and downloadable distributions, see the Python 3.1 website:

 http://www.python.org/download/releases/3.1/

See PEP 375 for release schedule details:

 http://www.python.org/dev/peps/pep-0375/



Enjoy,
-- Benjamin

Benjamin Peterson
benjamin at python.org
Release Manager
(on behalf of the entire python-dev team and 3.1's contributors)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] FINAL PROPULSION OPEN SOURCE ENGINE VARIANT FORTHE F-35 JOINT STRIKE FIGHTER

[Paul Barrett]

The other benefit of the military using open source software is that
is can save the taxpayers money over the short and long term. For some
projects it is a small percentage of the total cost.  However, for
others it can be significant portion of the cost, so don't discount
its use or its benefit.  Saving time and money is a good thing.

Cheers,
Paul

On Fri, Jun 12, 2009 at 9:30 PM, Nick Coghlan wrote:
> Raymond Hettinger wrote:
>>
>> [Matthew Wilkes]
>>> Oh, I didn't mean they should use proprietary software, just that in
>>> my experience the kind of people who are active in open source are
>>> quite anti-war, green, etc.  There are notable exceptions, but I know
>>> people who worry that their work will have military applications, and
>>> who turn down projects because of it.
>>
>> I question the whole notion of using open source in military weapons.
>> It seems like a rather basic violation of operational security.  Perhaps
>> your enemies will exploit your bugs instead of nicely reporting them
>> and submitting patches on SourceForge ;-)
>
> As Guido said, even the military are aware that there are major problems
> with the idea of security through obscurity. Plus most defence forces
> around the world are just as interested in saving a few bucks on
> software costs as any other organisation, particularly if they can
> reduce their reliance on a foreign software vendor in the process.
>
> As to the existence of open source developers that are willing to work
> with the military... as Matthew said, while they may not be particularly
> common, I can definitely say that they're around ;)
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
> ---
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/pebarrett%40gmail.com
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] ctime: I don't think that word means what you think it means.

[Zooko Wilcox-O'Hearn]

The stat module uses the "st_ctime" slot to hold two kinds of values
which are semantically different and which are frequently
confused with one another.  It chooses which kind of value to put in
there based on platform -- Windows gets the file creation time and all
other platforms get the "ctime".  The only sane way to use this API is
then to switch on platform:

if platform.system() == "Windows":
metadata["creation time"] = s.st_ctime
else:
metadata["unix ctime"] = s.st_ctime

(That is an actual code snippet from the Allmydata-Tahoe project.)

Many or even most programmers incorrectly think that unix ctime is file
creation time, so instead of using the sane idiom above, they write the
following:

metadata["ctime"] = s.st_ctime

thus passing on the confusion to the users of their metadata, who may
not be able to tell on which platform this metadata was created.   
This is

the situation we have found ourselves in for the Allmydata-Tahoe
project -- we now have a bunch of "ctime" values stored in our
filesystem and no way to tell which kind they were.

More and more filesystems such as ZFS and Mac HFS+ apparently offer
creation time nowadays.

I propose the following changes:

1.  Add a "st_crtime" field which gets populated on filesystems
(Windows, ZFS, Mac) which can do so.

That is hopefully not too controversial and we could proceed to do so
even if the next proposal gets bogged down:

2.  Add a "st_unixctime" field which gets populated *only* by the unix
ctime and never by any other value (even on Windows, where the unix
ctime *is* available even though nobody cares about it), and deprecate
the hopelessly ambiguous "st_ctime" field.

You may be interested in http://allmydata.org/trac/tahoe/ticket/628
("mtime" and "ctime": I don't think that word means what you think it
means.) where the Allmydata-Tahoe project is carefully unpicking the
mess we made for ourselves by confusing ctime with file-creation time.

This is ticket http://bugs.python.org/issue5720 .

Regards,

Zooko

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] FINAL PROPULSION OPEN SOURCE ENGINE VARIANT FOR THE F-35 JOINT STRIKE FIGHTER

[OMEGA RED]

Guido,
 
 
The reason why I use a code name is that it would be dangerous to reveal my 
true name to the world since there are those who are radical liberals who would 
like to think that there is no need for a U.S. military and that people such as 
myself should be eliminated.  Think of the U.S. military as the heroes that 
they truly are to protect its citizens from attack from other entities.  The 
U.S. military is here to serve and protect people such as yourself, not to act 
as the terrorist organization as bin laden would like you to think.    If any 
of you need any further evidence of the need of the U.S. military or the F-35 
for that matter, then I would suggest that you all take a nice long trip to 
Manhattan island in New York City and take some time to notice the fact that 
there appears to be a large hole where many buildings used to be located.  
 
 
Second, the biggest concern that I see in utilizing the python language in 
safety-critical systems is that it is a dynamically type language.  Unlike Ada 
which is safety statically type language.  These were just brainstorming ideas, 
but if you do not like those that brainstorm regarding the further development 
of python, then I guess I will be moving forward to some other language that is 
more capable to assist in the development of safety critical systems.  These 
were just brainstorming ideas.  
 
The idea being is to research onto the idea of developing a statically type 
variant of the python language for the development of software for safety 
critical systems.  Is this possible?  I am also wondering if it was possible to 
interface Ada programs with Python, similar to the method that has been 
utilized to interface FORTRAN with Python.  Is this also possible?  
 
 
 
Thank You.  
 
 
W108dab
 
 
 
 
 


--- On Sat, 6/13/09, Guido van Rossum  wrote:


From: Guido van Rossum 
Subject: Re: [Python-Dev] FINAL PROPULSION OPEN SOURCE ENGINE VARIANT FOR THE 
F-35 JOINT STRIKE FIGHTER
To: "OMEGA RED" omega_force2...@yahoo.com
Date: Saturday, June 13, 2009, 11:58 AM


I'm sorry, but I have so far three problems with your proposals.

(1) You use a code name.

(2) Your first message was ALL CAPS.

(3) You don't seem to know much about programming language design, or
you wouldn't propose such a vague non-starter as "adopt the
safety-critical charasteristics of the Ada programming language an
incorporate them into Python."

This is my last message to you.

--Guido

On Sat, Jun 13, 2009 at 7:27 AM, OMEGA RED wrote:
> Yes,
>
> I think that python developers would be great in the development of the
> FADEC controller as an open-source alternative to the propreitary FADEC
> controller software to the propulsion system for the F-35.  The FADEC
> controller is Full Authority Flight Digital Electronic Controller.
>
> I know that the python community could never possibly create the mechanical
> aspects of this proposed engine, but that does not mean that we cannot
> create something else.
>
> I believe that what could be done is to create a safety-critical version of
> python.  Such as adopt the safety-critical charasteristics of the Ada
> programming language an incorporate them into python.
>
> How about that as a project?  Create the python equivalent of Ada?
>
> Thank You,
>
> w108dab
>
>

> Subject: Re: [Python-Dev] FINAL PROPULSION OPEN SOURCE ENGINE VARIANT FOR
> THE F-35 JOINT STRIKE FIGHTER
> To: "OMEGA RED" 
> Date: Saturday, June 13, 2009, 6:16 AM
>
>
> I'm reasonably confused here, are you searching for Python developers?
>
>
>
>
> On Fri, Jun 12, 2009 at 7:01 PM, OMEGA RED 
> wrote:
>>
>>
>> TO ALL,
>>
>>
>> I AM HAPPY TO SAY THAT I AM NOW IN THE PROCESS OF DEVELOPING A WEBSITE FOR
>> THE STATED PURPOSE OF COMBINING SOME OF THE BEST MINDS IN THE WORLD.  THIS
>> PROJECT WILL BE A MEANS TO DEVELOP THE FIRST AND ONLY COMPLETELY OPEN SOURCE
>> VARIANT OF THE PROPULSION ENGINE FOR THE F-35 JOINT STRIKE FIGHTER.  WHICH
>> MEANS THAT EVERYTHING ABOUT THE DESIGN, DEVELOPMENT, AND CONSTRUCTION OF THE
>> ENGINE WILL BE COMPLETELY AVAILABLE TO THE PUBLIC AND TO ANY ENGINE
>> MANUFACTURE FREE OF ANY REQUIREMENTS.
>>
>> THIS ENGINE WILL BE CALLED THE PHOENIX NexT F-200 ENGINE.
>>
>> THIS ENGINE WILL ALSO BE A POTENTIAL THIRD AND FINAL ALTERNATIVE ENGINE
>> FOR THE JOINT STRIKE FIGHTER.
>>
>> THIS ENGINE WILL BE STATED AS BEING A COMPETITOR WITH BOTH THE F-135 AND
>> THE F-136 ENGINE, WHICH ARE PROVIDED BY BOTH PRATT-WHITNEY AND GENERAL
>> ELECTRIC/ ROLLS ROYCE.
>>
>> THIS ENGINE WILL UTILIZE PYTHON FOR THE MAJOR PORTION OF THE SIMULATION,
>> RESEARCH AND DEVELOPMENT STAGES FOR THE DEVELOPMENT OF THE ENGINE.  THE
>> CONSTRUCTION OF THE MATHEMATICAL PROCESSING OF THE REQUIRED NONLINEAR
>> CONTROLS WILL BE BASED ON A SPECIALIZED VERSION OF GROUP THEORY FOR THE
>> DESIGN AND CONSTRUCTION OF THE NONLINEAR CONTROL SYSTEMS.
>>
>>
>> THE PURPOSE OF THE DEVELOPMENT OF THE ENGINE WILL BE TO CONSTRUCT AN
>> ENGINE FOR THE F-35 THAT WILL BE AS RELIABLE AND CAPABLE A

Re: [Python-Dev] FINAL PROPULSION OPEN SOURCE ENGINE VARIANT FOR THE F-35 JOINT STRIKE FIGHTER

[Arc Riley]

Enough is enough guys.  As entertaining as this thread has been, shouldn't
we be focused on the 3.1 release?

Don't feed the trolls.  Ok so one wandered in, but nobody needed to respond
and it can only get worse from here.

Please just flag the offending address(es) for moderation and ask them
politely to keep their posts to this list on-topic for core Python
development.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] io.BufferedReader.peek() Behaviour in python3.1

[Greg Ewing]

Antoine Pitrou wrote:

The original docstring for peek() says:

...we
do at most one raw read to satisfy it.

In that light, I'm not sure it's a bug


It may be behaving according to the docs, but is that
behaviour useful?

Seems to me that if you're asking for n bytes, then it's
because you're doing some kind of parsing that requires
lookahead, and nothing less than n bytes will do.

I think it would be more useful if the "at most one
raw read" part were dropped. That would give it the
kind of deterministic behaviour generally expected
when dealing with buffered streams.

--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] io.BufferedReader.peek() Behaviour in python3.1

[Antoine Pitrou]

Greg Ewing  canterbury.ac.nz> writes:
> 
> I think it would be more useful if the "at most one
> raw read" part were dropped. That would give it the
> kind of deterministic behaviour generally expected
> when dealing with buffered streams.

As I already told Nick: please propose an implementation scheme.

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] ctime: I don't think that word means what you think it means.

[Greg Ewing]

Zooko Wilcox-O'Hearn wrote:


1.  Add a "st_crtime" field which gets populated on filesystems
(Windows, ZFS, Mac) which can do so.


"crtime" looks rather too similar to "ctime" for my
liking. People who think that the "c" in "ctime"
means "creation" are still likely to confuse them.

Why not give it a more explicit name, such
as "st_creationtime"?

--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Iterator version of contextlib.nested

[Nick Coghlan]

Hagen Fürstenau wrote:
> I guess this is much too late for 3.1, but could we then at least
> un-deprecate "contextlib.nested" for now? As it is, you get a
> DeprecationWarning for something like
> 
> with contextlib.nested(*my_managers):
> 
> without any good way to get rid of it.

I actually almost asked for that to be changed to a
PendingDeprecationWarning when it was first added - Benjamin, do you
mind if I downgrade this warning to a pending one post rc2?

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
---
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Distributed computing & sending the interpreter

[Jeremy Cowles]

Hi all,
I apologize if this question is misplaced, I wasn't sure which list to post
it in.

I'm working on a distributed computing project (PyMW and BOINC) where we are
sending Python scripts to client machines. Currently, we make two very
unlikely assumptions: that Python 2.5 is installed and that the interpreter
is available on the PATH.

We are looking at our options to remove this assumption and the two most
likely are redistributing the entire Python installation (for each supported
platform) and embedding the interpreter in a custom executable and sending
select parts of the standard library with it (to reduce size).

It seems like we would have to pre-compile for each different platform,
which is a pain and sending the entire installation could be tricky.

I am looking for alternatives, comments and suggestions. Any help would be
greatly appreciated.

Thanks,
Jeremy
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Distributed computing & sending the interpreter

[Aahz]

On Sat, Jun 13, 2009, Jeremy Cowles wrote:
>
> I apologize if this question is misplaced, I wasn't sure which list to
> post it in.
>
> I'm working on a distributed computing project (PyMW and BOINC) where
> we are sending Python scripts to client machines. Currently, we make
> two very unlikely assumptions: that Python 2.5 is installed and that
> the interpreter is available on the PATH.

Definitely the wrong list -- python-dev is for people working on the core
interpreter and libraries.  comp.lang.python would be the standard place,
but you might also find some good advice on the new list concurrency-sig.
-- 
Aahz (a...@pythoncraft.com)   <*> http://www.pythoncraft.com/

"Many customs in this life persist because they ease friction and promote
productivity as a result of universal agreement, and whether they are
precisely the optimal choices is much less important." --Henry Spencer
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Distributed computing & sending the interpreter

[Jeremy Cowles]

>
> Definitely the wrong list -- python-dev is for people working on the core
> interpreter and libraries.  comp.lang.python would be the standard place,
> but you might also find some good advice on the new list concurrency-sig.


Sorry for the list pollution, I will repost it there.

Thanks,
Jeremy
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] io.BufferedReader.peek() Behaviour in python3.1

[Cameron Simpson]

On 14Jun2009 12:33, Greg Ewing  wrote:
> Antoine Pitrou wrote:
>> The original docstring for peek() says:
>>
>> ...we
>> do at most one raw read to satisfy it.
>>
>> In that light, I'm not sure it's a bug
>
> It may be behaving according to the docs, but is that
> behaviour useful?
>
> Seems to me that if you're asking for n bytes, then it's
> because you're doing some kind of parsing that requires
> lookahead, and nothing less than n bytes will do.
>
> I think it would be more useful if the "at most one
> raw read" part were dropped. That would give it the
> kind of deterministic behaviour generally expected
> when dealing with buffered streams.

Is it possible to access the buffer? I see nothing in the docs.

People seem to want peek() to be "read() without moving the read
offset", which it almost seems to be. Nick and Greg both want it to
really be that, and thus do enough raw reads to get "n" bytes; Nick
wants a peek1() like read1(), too.

It has a pleasing feel to me, too. But ...

For myself, I'd expect more often to want to see if there's stuff in the
buffer _without_ doing any raw reads at all. A peek0(n), if you will:

  Read and return up to n bytes without calling on the raw stream.

It feels like peek is trying to span both extremes and doesn't satisfy
either really well.

If peek gets enhanced to act like read in terms of the amount of data
returned, should there not be a facility to examine buffered data
without raw reads?

Cheers,
-- 
Cameron Simpson  DoD#743
http://www.cskk.ezoshosting.com/cs/

Being on a Beemer and not having a wave returned by a Sportster is like
having a clipper ship's hailing not returned by an orphaned New Jersey
solid waste barge.   - OTL
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] io.BufferedReader.peek() Behaviour in python3.1

[Cameron Simpson]

On 14Jun2009 15:16, I wrote:
| Is it possible to access the buffer? I see nothing in the docs.

I've just found getvalue() in IOBase. Forget I said anything.
It seems to be my day for that kind of post:-(
-- 
Cameron Simpson  DoD#743
http://www.cskk.ezoshosting.com/cs/

These are but a few examples of what can happen when the human mind is
employed to learn, to probe, to question as opposed to merely keeping the
ears from touching. - rec.humor.funny 90.07.16
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com