On 3/12/2011 1:55 PM, Fredrik Johansson wrote:
Consider sorting a list of pairs representing fractions. This can be
done easily in Python 2.x with the comparison function lambda
(p,q),(r,s): cmp(p*s, q*r). In Python 2.6, this is about 40 times
faster than using fractions.Fraction as a key
On 3/12/2011 3:43 AM, Nick Coghlan wrote:
I posted my rough notes and additional write-ups for Wednesday's VM
summit and Thursday's language summit:
http://www.boredomandlaziness.org/2011/03/python-vm-summit-rough-notes.html
2.7 to 3.2
- treat PyPy Python 3 dialect like a major Python
On 3/12/2011 2:09 PM, Terry Reedy wrote:
I believe that if the integer field were padded with leading blanks as
needed so that all are the same length, then no key would be needed.
Did you mean that if the integer field were converted to string and
padded with leading blanks...?
Otherwise
On 3/12/2011 7:21 PM, Terry Reedy wrote:
(Ok, I assumed that the 'word' field does not include any of
!#$%'()*+. If that is not true, replace comma with space or even a
control char such as '\a' which even precedes \t and \n.)
OK, I agree the above was your worst assumption, although you need
On 3/8/2011 12:02 PM, Terry Reedy wrote:
On 3/7/2011 9:31 PM, Reliable Domains wrote:
The launcher need not be called python.exe, and maybe it would be
better called #@launcher.exe (or similar, depending on its exact
function details).
I do not know that the '#@' part is about, but pygo
On 3/8/2011 8:02 PM, Toshio Kuratomi wrote:
On Tue, Mar 08, 2011 at 06:43:19PM -0800, Glenn Linderman wrote:
On 3/8/2011 12:02 PM, Terry Reedy wrote:
On 3/7/2011 9:31 PM, Reliable Domains wrote:
The launcher need not be called python.exe, and maybe it would be
better
On 3/8/2011 9:06 PM, Mark Hammond wrote:
On 9/03/2011 1:43 PM, Glenn Linderman wrote:
I'm of the opinion that attempting to parse a Unix #! line, and intuit
what would be the equivalent on Windows is unnecessarily complex and
error prone, and assumes that the variant systems are configured
On 3/8/2011 10:27 PM, Mark Hammond wrote:
On 9/03/2011 5:05 PM, Glenn Linderman wrote:
Standard installation paths are accepted by about 99% of the users, so
embedding standard installation paths can work well for that batch of
users. Of course, Windows changes the standard path periodically
On 3/7/2011 4:00 PM, Michael Foord wrote:
On 07/03/2011 23:52, Greg Ewing wrote:
Michael Foord wrote:
- I doubt calling it python.exe will fly, but I'm not sure. If
so what will you call what is currently 'python.exe'? - if not then
python foo.py on the command line will *still* not
On 3/7/2011 2:18 PM, James Y Knight wrote:
On Mar 7, 2011, at 3:49 PM, Paul Moore wrote:
The launcher could also (as per Mark's suggestion) interpret a shebang
line in the script, so that scripts could specify their required
version without needing a different command,or multiple
On 3/6/2011 7:07 AM, Michael Urman wrote:
I think Glenn Linderman hit the use cases on the head; I'm unclear why
he was against the overhead of a helper executable. The things I would
really want solutions for are these:
* double click on a script, and have it launch the right python (2 or
3
On 3/4/2011 5:21 AM, Nick Coghlan wrote:
On Fri, Mar 4, 2011 at 10:59 PM, Michael Foord
fuzzy...@voidspace.org.uk wrote:
Should any of this also apply to Mac OS X and Windows?
Any platform that considers itself unix-like in this context can
decide to follow it, we aren't fussy (e.g. Cygwin
On 3/4/2011 1:35 PM, Martin v. Löwis wrote:
I'd still like the PEP to tell me whether it's python3w.exe or
pythonw3.exe (and yes, that's bikeshedding - so somebody just tell
me). It would also be good if the PEP took a position on providing
pythonXY.exe binaries on Windows (with the related
On 1/27/2011 12:26 PM, James Y Knight wrote:
On Jan 27, 2011, at 2:06 PM, Stefan Behnel wrote:
Martin v. Löwis, 24.01.2011 21:17:
The Py_UNICODE type is still supported but deprecated. It is always
defined as a typedef for wchar_t, so the wstr representation can double
as Py_UNICODE
On 1/26/2011 4:47 PM, Toshio Kuratomi wrote:
There's one further case that I am worried about that has no real
transfer. Since people here seem to think that unicode module names are
the future (for instance, the comments about redefining the C locale to
include utf-8 and the comments about
On 1/20/2011 12:27 PM, Glyph Lefkowitz wrote:
To support the latter, could we just make sure that zipimport has a
consistent, non-locale-or-operating-system-dependent interpretation of
encoding? That way a distributed egg would be importable from a zipfile
regardless of how screwed up the
On 1/19/2011 11:31 AM, Victor Stinner wrote:
If we decide to reject non-ASCII module names, it should be done on any
operating systems, not only on Windows.
Since Python allows non-ASCII variable names, I think it should allow
non-ASCII module names also, on any platform that supports the
On 1/19/2011 8:39 PM, Toshio Kuratomi wrote:
use this::
import cafe as café
When you do things this way you do not have to translate between unknown
encodings into unicode. Everything is within python source where you have
a defined encoding.
This is a great way of converting
On 1/19/2011 9:11 PM, Glyph Lefkowitz wrote:
On Jan 20, 2011, at 12:02 AM, Glenn Linderman wrote:
But for local code, having to think up an ASCII name for a module
rather than use the obvious native-language name, is just
brain-burden when creating the code.
Is it really? You already had
On 1/19/2011 11:20 PM, Toshio Kuratomi wrote:
On Wed, Jan 19, 2011 at 09:02:17PM -0800, Glenn Linderman wrote:
On 1/19/2011 8:39 PM, Toshio Kuratomi wrote:
use this::
import cafe as café
When you do things this way you do not have to translate between unknown
encodings
On 1/6/2011 3:50 PM, And Clover wrote:
ISO-8859-1 is the encoding specified by the HTTP RFC
Please could I have the reference to that specification? I only recall
ASCII and UTF-8 in my readings of various things HTTP and HTML, for
headers, and form data. Naturally data pages can have any
On 1/6/2011 7:37 PM, Stephen J. Turnbull wrote:
Glenn Linderman writes:
On 1/6/2011 3:50 PM, And Clover wrote:
ISO-8859-1 is the encoding specified by the HTTP RFC
Please could I have the reference to that specification?
RFC 2616 (probably obsolete by now, but IRC ISO 8859/1
On 12/28/2010 4:16 AM, Vinay Sajip wrote:
How does that sound?
Sounds pretty rational, overall.
If the leave_enabled flag can be turned on/off by the application, then
I agree the arms race is unlikely.
I didn't dig through the logging docs to discover if there is an API
that returns a
On 12/27/2010 7:29 AM, Vinay Sajip wrote:
The logging configuration calls fileConfig and dictConfig disable all existing
loggers, and enable only loggers explicitly named in the configuration (and
their children). Although there is a disable_existing_loggers option for each
configuration API,
On 12/20/2010 6:31 AM, Antoine Pitrou wrote:
Diffing is completely an implementation detail of how the failure
messages are generated. The important thing is that failure messages
make sense with respect to actual result and expected result.
Which, again, they don't. Let's see:
On 12/18/2010 1:04 PM, Georg Brandl wrote:
Am 13.12.2010 21:08, schrieb Glenn Linderman:
On 12/13/2010 11:39 AM, Mark Dickinson wrote:
my_thing = Thing(
foo = Foo(arg1, arg2, ...),
bar = Bar(arg3, arg4, ...),
...
)
and I've found the trailing comma very convenient during
On 12/15/2010 10:39 AM, Antoine Pitrou wrote:
Hello,
I would like to remove HTTP 0.9 support from http.client and
http.server. I've opened an issue at http://bugs.python.org/issue10711
for that. Would anyone think it's a bad idea?
(HTTP 1.0 was devised in 1996)
Please address the following
On 12/15/2010 1:25 PM, Antoine Pitrou wrote:
On Wed, 15 Dec 2010 12:58:51 -0800
Glenn Lindermanv+pyt...@g.nevcal.com wrote:
On 12/15/2010 10:39 AM, Antoine Pitrou wrote:
Hello,
I would like to remove HTTP 0.9 support from http.client and
http.server. I've opened an issue at
On 12/13/2010 11:17 AM, Antoine Pitrou wrote:
On Mon, 13 Dec 2010 14:09:02 -0500
Alexander Belopolskyalexander.belopol...@gmail.com wrote:
On Mon, Dec 13, 2010 at 11:54 AM, Guido van Rossumgu...@python.org wrote:
I'm at least +0 on
allowing trailing commas in the situation the OP mentioned.
On 12/13/2010 11:39 AM, Mark Dickinson wrote:
my_thing = Thing(
foo = Foo(arg1, arg2, ...),
bar = Bar(arg3, arg4, ...),
...
)
and I've found the trailing comma very convenient during refactoring
and API experimentation. (There's still good fun to be had arguing
about the
On 12/13/2010 1:55 PM, Raymond Hettinger wrote:
It seems to me that a trailing comma in an argument list is more likely to be a
user error than a deliberate comma-for-the-future.
It seems to me that a trailing comma, especially in the case of one
parameter per line, is a deliberate
On 12/12/2010 2:26 PM, Paul Moore wrote:
The thing*I* hit very early was wanting to add a command lime option
to my script to set the logging level. I'd have liked to be able to
add --log=INFO/DEBUG/... but to do that I seem to need to write my own
mapping between level names and numbers. A
On 12/12/2010 9:41 AM, Vinay Sajip wrote:
Gosh, Nick, that was fast! I'm still making changes, but thanks for spotting and
highlighting the typos and omissions. I've just checked in a further update;
hopefully it'll get built soon so we can all see the latest changes.
I'm not as fast as Nick,
On 12/11/2010 12:00 AM, Nick Coghlan wrote:
On Sat, Dec 11, 2010 at 4:25 PM, Glenn Lindermanv+pyt...@g.nevcal.com wrote:
On 12/10/2010 9:24 PM, Nick Coghlan wrote:
This could actually make a reasonably good basic for a task oriented
subsection of the logging documentation. Something like:
On 12/11/2010 1:28 AM, Vinay Sajip wrote:
Nick Coghlanncoghlanat gmail.com writes:
The lazy stream handler might be useful to make public in some way.
For example, rather than hardcoding sys.stderr, it could take a
callable that it uses to retrieve the stream. That kind of change can
wait
On 12/11/2010 1:07 AM, Nick Coghlan wrote:
As Glenn mentioned later in the thread, the output of logging.info and
logging.debug messages is*distinct* from an application's normal
operational output that is emitted on stdout. So making it easy to
emit such messages on stderr is the right thing
On 12/11/2010 3:52 AM, Vinay Sajip wrote:
I will try to incorporate more basic examples at the top of the documentation,
but surely you don't want me to add more verbiage about basicConfig when your
overall feeling is that there's too much documentation?
I try not to post unless I feel there
On 12/10/2010 12:06 AM, Vinay Sajip wrote:
This simplistic easy usage somewhat echo's Glenn's comment on this thread
about logging seeming way to daunting as presented today. It needn't be.
Indeed, and the very first code sample in the logging documentation shows
exactly the simplistic
On 12/9/2010 8:29 PM, Gregory P. Smith wrote:
Exactly. All I ever recommend people do is:
import logging
...
logging.warn('doing something a bit odd.')
...
for x in thing:
logging.debug('working on %r', x)
...
And be done with it. If they are controlling their __main__
On 12/10/2010 12:49 PM, Antoine Pitrou wrote:
And yet, I have helped many people who were baffled by exactly what
Bill observed: logging.info() didn't do anything. Maybe the default
should be INFO?
Funny, because displaying only errors and silencing other messages is
exactly what I expected
On 12/10/2010 9:06 PM, Nick Coghlan wrote:
Anyway, the shortest way I could find of setting this up (debug
silenced, info written to stdout, warning and above written to
stderr):
import sys, logging
root = logging.getLogger()
# Turns out the level of the root logger is set to WARNING
On 12/9/2010 12:26 AM, Vinay Sajip wrote:
Glenn Lindermanv+pythonat g.nevcal.com writes:
Or what am I missing?
That threads are not necessarily dedicated to apps, in a real world setting.
Depending on the server implementation, a single thread could be asked to handle
requests for
On 12/8/2010 4:15 AM, Vinay Sajip wrote:
You're complaining about too much documentation?! Don't measure it by weight!
On 12/8/2010 5:57 AM, Vinay Sajip wrote:
Of course I understand I could be wrong
about this, but I don't recall when a stdlib maintainer has said to me, I want
to start using
On 12/8/2010 9:43 AM, Vinay Sajip wrote:
offtopic
As am off-topic example, Armin Ronacher kept on saying in various posts and
presentations that you couldn't use stdlib logging for web applications, that
there were fundamental problems with it. But when he actually sent me his
specific problem
On 12/5/2010 10:03 AM, s...@pobox.com wrote:
Glenn On 12/4/2010 3:07 PM, Paul Moore wrote:
The original goal was for subprocess to replace os.system, os.popen,
os.spawn, etc. That's never quite happened because subprocess is just
a little bit too conceptually complex
On 12/4/2010 3:07 PM, Paul Moore wrote:
The original goal was for subprocess to replace os.system, os.popen,
os.spawn, etc. That's never quite happened because subprocess is just
a little bit too conceptually complex for those basic tasks.
Is that way? I didn't find it particularly hard to
On 11/27/2010 2:51 AM, Nick Coghlan wrote:
Not quite. I'm suggesting a factory function that works for any value,
and derives the parent class from the type of the supplied value.
Nick, thanks for the much better implementation than I achieved; you
seem to have the same goals as my
On 11/27/2010 12:56 PM, Glenn Linderman wrote:
On 11/27/2010 2:51 AM, Nick Coghlan wrote:
Not quite. I'm suggesting a factory function that works for any value,
and derives the parent class from the type of the supplied value.
Nick, thanks for the much better implementation than I achieved
So the following code defines constants with associated names that get
put in the repr.
I'm still a Python newbie in some areas, particularly classes and
metaclasses, maybe more.
But this Python 3 code seems to create constants with names ... works
for int and str at least.
Special case for
On 11/22/2010 8:33 AM, Guido van Rossum wrote:
On Sun, Nov 21, 2010 at 9:40 PM, Glenn Lindermanv+pyt...@g.nevcal.com wrote:
In reviewing my notes from my experimentations with CGIHTTPServer
(Python2.6) and then http.server (Python 3.2a4), I note one behavior I
haven't reported as a bug,
On 11/23/2010 3:55 AM, Martin v. Löwis wrote:
Am 23.11.2010 11:55, schrieb Amaury Forgeot d'Arc:
Hi,
2010/11/23 Glenn Lindermanv+pyt...@g.nevcal.com:
File C:\Python32\lib\random.py, line 108, in seed
a = int.from_bytes(_urandom(32), 'big')
WindowsError: [Error -2146893818] Invalid
On 11/22/2010 2:56 PM, Tim Lesher wrote:
On Mon, Nov 22, 2010 at 16:54, Glenn Lindermanv+pyt...@g.nevcal.com wrote:
I suppose it is possible that some environment variables are used by Python
directly (but I can't seem to find a documented list of them) although I
would expect that usage to be
On 11/23/2010 12:33 PM, Martin v. Löwis wrote:
In any case, VS 2010 will stop using SxS for the CRT.
Good news! Maybe M$VC will become a useful compiler yet again :)
___
Python-Dev mailing list
Python-Dev@python.org
On 11/23/2010 11:34 AM, Guido van Rossum wrote:
The best example of the utility of enums even for Python is bool. I
resisted this for the longest time but people kept asking for it. Some
properties of bool:
(a) bool is a (final) subclass of int, and an int is acceptable in a
pinch where a bool
Where might I find the bug #427345 that is referred to in a comment
inside http.server ? Here is a code excerpt:
# throw away additional data [see bug #427345]
while select.select([self.rfile._sock], [], [], 0)[0]:
if not self.rfile._sock.recv(1):
On 11/21/2010 8:39 PM, R. David Murray wrote:
On Sun, 21 Nov 2010 19:59:54 -0800, Glenn Lindermanv+pyt...@g.nevcal.com
wrote:
On 11/21/2010 9:18 AM, R. David Murray wrote:
I want to look at the CGI issue, but I'm not sure when I'll get to it.
Actually, since this code was working before
On 11/22/2010 8:33 AM, Guido van Rossum wrote:
On Sun, Nov 21, 2010 at 9:40 PM, Glenn Lindermanv+pyt...@g.nevcal.com wrote:
In reviewing my notes from my experimentations with CGIHTTPServer
(Python2.6) and then http.server (Python 3.2a4), I note one behavior I
haven't reported as a bug, nor do
On 11/21/2010 9:18 AM, R. David Murray wrote:
I want to look at the CGI issue, but I'm not sure when I'll get to it.
Actually, since this code was working before 3.x, and if email.parser
can now accept binary streams, it seems like maybe the only thing that
might be wrong is that presently
In reviewing my notes from my experimentations with CGIHTTPServer
(Python2.6) and then http.server (Python 3.2a4), I note one behavior I
haven't reported as a bug, nor do I know where to start to figure it
out, other than experimentally.
The experiment: launching CGIHTTPServer without
On 11/20/2010 3:38 AM, Éric Araujo wrote:
Hello
cgitb.enable(0,d:\temp)
Isn’t that expanded to “d:tabemp”?
Oops. Yes, that fixes the problem with creation of the temp file,
thanks for catching that. I now get a complete report of the original
error in the temp file (below). I am a
On 11/20/2010 10:19 AM, Glenn Linderman wrote:
Oops. Yes, that fixes the problem with creation of the temp file,
thanks for catching that. I now get a complete report of the
original error in the temp file (below). I am a bit less confused
now... but it seems that there are still a number
So maybe this is the wrong forum, if so please tell me what the right
forum is for each of the various pieces. I'm assuming that I should
file some bugs in the tracker, but I'm not exactly sure whether to file
them on cgitb, http.server, or subprocess, or all of the above. Pretty
sure there
On 11/19/2010 7:48 PM, Glenn Linderman wrote:
One of the cgitb outputs from my attempt to serve the binary file
claims that my CGI script's output file (which comes from a subprocess
PIPE) is a TextIOWrapper with encoding cp1252. Maybe that is the
default that comes when a new Python
On 10/31/2010 2:02 PM, Benjamin Peterson wrote:
2010/10/31 Antoine Pitrousolip...@pitrou.net:
On Sun, 31 Oct 2010 16:39:44 -0400
Eric Smithe...@trueblade.com wrote:
What are your thoughts on adding a str.format_from_mapping (or similar
name, maybe the suggested format_map) to 3.2?
On 10/31/2010 3:32 PM, Eric Smith wrote:
On 10/31/2010 6:28 PM, Glenn Linderman wrote:
On 10/31/2010 2:02 PM, Benjamin Peterson wrote:
2010/10/31 Antoine Pitrousolip...@pitrou.net:
On Sun, 31 Oct 2010 16:39:44 -0400
Eric Smithe...@trueblade.com wrote:
What are your thoughts on adding
On 9/24/2010 3:10 PM, Greg Ewing wrote:
Paul Moore wrote:
I dug into this once, and as far as I could tell, it's possible to get
the information on Windows, but there's no way on Linux to ask the
filesystem.
Maybe we could use a heuristic such as:
1) Search the directory for an exact match
On 9/23/2010 7:41 AM, Barry Warsaw wrote:
Our development processes are*primarily* independent of Python version, so I
don't think they should be tied to our source tree, and our CPython source
tree at that. I suspect the version-dependent instructions will be minimal
and can be handled by
On 7/26/2010 7:36 AM, Guido van Rossum wrote:
According to CSP advicates, this approach will break down when you
need more than 8-16 cores since cache coherence breaks down at 16
cores. Then you would have to figure out a message-passing approach
(but the messages would have to be very fast).
On 3/25/2010 8:13 AM, Mark Dickinson wrote:
On Thu, Mar 25, 2010 at 3:05 PM, Nick Coghlanncogh...@gmail.com wrote:
Mark Dickinson wrote:
On Thu, Mar 25, 2010 at 2:08 PM, Nick Coghlanncogh...@gmail.com wrote:
Jesus Cea wrote:
But IEEE 754 was created by pretty
On 3/25/2010 4:14 PM, Guido van Rossum wrote:
On Thu, Mar 25, 2010 at 12:31 PM, Glenn Lindermanv+pyt...@g.nevcal.com wrote:
It is my understand that even bit-for-bit identical NaN values will compare
unequal according to IEEE 754 rules.
I would have no problem with Python interning each
On 3/25/2010 9:35 PM, Greg Ewing wrote:
Steven D'Aprano wrote:
What do we do with Decimal? Aren't we committed to matching the
Decimal standard,
It's been pointed out that the Decimal standard only defines
some abstract operations, and doesn't mandate that they
be mapped onto any particular
On 3/19/2010 9:20 PM, Nick Coghlan wrote:
Glenn Linderman wrote:
The same person that would expect both
0 == 0
0.0 == 0.0
to be False... i.e. anyone that hasn't coded in Perl for too many years.
Completely different - that is comparing numbers to strings.
One can
On 3/19/2010 4:50 AM, Antoine Pitrou wrote:
Glenn Lindermanglennat nevcal.com writes:
On the other hand, if the default behavior is to do an implicit
conversion, I don't know of any way that that could be turned into an
exception for those coders that don't want or don't like the
On 3/19/2010 11:43 AM, Terry Reedy wrote:
On 3/19/2010 2:11 PM, Antoine Pitrou wrote:
Raymond Hettingerraymond.hettingerat gmail.com writes:
The reason to prefer an exception is that decimal/float comparisons
are more likely to be a programmer error than an intended behavior.
If you
On 3/19/2010 12:50 PM, Mark Dickinson wrote:
Hah. This is a very good point, and one I'd somehow missed up until
now. I don't think we*can* reasonably make equality comparisons
raise NotImplemented (in either 2.x or 3.x), since that messes up
containment tests: something like 1.0 in {2,
On 3/19/2010 2:50 PM, Guido van Rossum wrote:
I'd like to reboot this thread.
I'll go along with that idea!
I've been spinning this topic in my
head for most of the morning, and I think we should seriously
reconsider allowing mixed arithmetic involving Decimal, not just mixed
comparisons.
On 3/19/2010 4:58 PM, Antoine Pitrou wrote:
Glenn Lindermanv+pythonat g.nevcal.com writes:
If there's a bug in your __eq__ method, it may or may not raise an
exception, which may or may not get you wrong containment results. But
it will probably get you buggy results, somehow or
On 3/19/2010 5:18 PM, Michael Foord wrote:
will probably get you buggy results, somehow or another. That's what
design, code reviews, and testing are for.
We'll have to agree to disagree then. If you want error silencing
by default,
Python is not the language you are looking for.
We can
On 3/19/2010 5:20 PM, Michael Foord wrote:
On 20/03/2010 00:19, Glenn Linderman wrote:
On 3/19/2010 5:18 PM, Michael Foord wrote:
will probably get you buggy results, somehow or another. That's what
design, code reviews, and testing are for.
We'll have to agree to disagree then. If you want
On 3/18/2010 5:23 AM, Steven D'Aprano wrote:
On Thu, 18 Mar 2010 08:58:25 am Raymond Hettinger wrote:
On Mar 17, 2010, at 1:59 PM, Steven D'Aprano wrote:
On Thu, 18 Mar 2010 07:44:21 am Raymond Hettinger wrote:
The spectrum of options from worst to best is
1) compare but
On 3/18/2010 12:45 PM, Robert Kern wrote:
On 2010-03-18 13:27 PM, Glenn Linderman wrote:
As any non-naïve float user is aware, the proper form of float
comparisons is not to use or or == or !=, but rather, instead of
using (to follow along with your example), one should use:
Decimal('1.1
On 3/18/2010 12:34 PM, Steven D'Aprano wrote:
On Fri, 19 Mar 2010 05:27:06 am Glenn Linderman wrote:
Do you envisage any problems from allowing this instead?
Decimal('1.1') 2.2
True
Yes.
As any non-naïve float user is aware, the proper form of float
On 3/18/2010 2:48 PM, Nick Coghlan wrote:
When there is a clear, correct way (based on Decimal.from_float) to make
numeric comparison behave in accordance with the rules of mathematics,
do we really want to preserve strange, unintuitive behaviour like the above?
Cheers,
Nick.
I'm aware of
On 3/18/2010 6:18 PM, Antoine Pitrou wrote:
Glenn Lindermanv+pythonat g.nevcal.com writes:
On 3/18/2010 2:48 PM, Nick Coghlan wrote:
When there is a clear, correct way (based on Decimal.from_float) to make
numeric comparison behave in accordance with the rules of mathematics,
do we
On approximately 3/3/2010 5:49 PM, came the following characters from
the keyboard of Barry Warsaw:
On Mar 03, 2010, at 07:37 PM, Jim Jewett wrote:
I understand the need to ship without source -- but why does that
require supporting .pyc (or .pyo) -only?
Couldn't vendors just replace the
On approximately 2/28/2010 3:22 PM, came the following characters from
the keyboard of Greg Ewing:
Glenn Linderman wrote:
if the command line/runpy can do it, the importer could do it. Just
a matter of desire and coding. Whether it is worth pursuing further
depends on people's perceptions
On approximately 2/26/2010 2:55 PM, came the following characters from
the keyboard of Brett Cannon:
Maybe Greg's and my response to the mention of dropping this feature
is too strong -- after all we're both dinosaurs. And maybe the
developers who want the feature can write their
On approximately 2/26/2010 5:13 PM, came the following characters from
the keyboard of Brett Cannon:
On Fri, Feb 26, 2010 at 15:35, Glenn Linderman v+pyt...@g.nevcal.com
mailto:v%2bpyt...@g.nevcal.com wrote:
On approximately 2/26/2010 2:55 PM, came the following characters
from
On approximately 2/26/2010 8:31 PM, came the following characters from
the keyboard of Brett Cannon:
I'm not sure why what you did is different than what I did,
-M uses runpy which is not directly equivalent to importing.
OK, that gives me some good keywords for searching
On approximately 2/25/2010 8:51 PM, came the following characters from
the keyboard of Meador Inge:
Hi All,
Recently some discussion began in the issue 3132 thread
(http://bugs.python.org/issue3132) regarding
implementation of the new struct string syntax for PEP 3118. Mark
Dickinson
On approximately 2/19/2010 1:18 PM, came the following characters from
the keyboard of P.J. Eby:
At 01:49 PM 2/19/2010 -0500, Ian Bicking wrote:
I'm not sure how this should best work on Windows (without symlinks,
and where things generally work differently), but I would hope if
this idea is
On approximately 2/19/2010 7:52 PM, came the following characters from
the keyboard of Eric Smith:
Glenn Linderman wrote:
On approximately 2/19/2010 1:18 PM, came the following characters
from the keyboard of P.J. Eby:
At 01:49 PM 2/19/2010 -0500, Ian Bicking wrote:
I'm not sure how
On approximately 1/27/2010 1:08 AM, came the following characters from
the keyboard of Glenn Linderman:
Without reference to distutils, it seems the pieces are:
1) a way to decide what to include in the package
2) code that knows where to put what is included, on one or more
platforms
3
On approximately 1/30/2010 4:00 PM, came the following characters from
the keyboard of Barry Warsaw:
When the Python executable is given a `-R` flag, or the environment
variable `$PYTHONPYR` is set, then Python will create a `foo.pyr`
directory and write a `pyc` file to that directory with the
On approximately 2/4/2010 2:28 PM, came the following characters from
the keyboard of Eric Smith:
Glenn Linderman wrote:
On approximately 1/30/2010 4:00 PM, came the following characters
from the keyboard of Barry Warsaw:
When the Python executable is given a `-R` flag, or the environment
On approximately 2/2/2010 7:05 PM, came the following characters from
the keyboard of Guido van Rossum:
On Tue, Feb 2, 2010 at 5:41 PM, Glenn Lindermanv+pyt...@g.nevcal.com wrote:
On approximately 2/2/2010 4:28 PM, came the following characters from the
keyboard of Guido van Rossum:
On approximately 2/2/2010 4:28 PM, came the following characters from
the keyboard of Guido van Rossum:
Argh. zipfiles are way to complex to be writing.
Agreed. But in reading that, it somehow triggered a question: does
zipimport only work for zipfiles, or does it work for any archive format
On approximately 1/26/2010 7:35 PM, came the following characters from
the keyboard of David Lyon:
Glen wrote:
So let's say that the .zip file was dropped onto the Desktop or start
menu. It would have an icon, then.
It would have an icon. But nothing to identify it as a python
On approximately 1/26/2010 7:50 PM, came the following characters from
the keyboard of Cameron Simpson:
My point was that I look on python builtins like list and dict as highly
optimised, highly efficient facilities. That means that I expect a list
to be very very much like a linear array as one
Yesterday, I said:
On approximately 1/25/2010 9:27 PM, came the following characters
from the keyboard of David Lyon:
Firstly, it doesn't create create desktop shortcuts - sorry users
need those. Where do the programs go?
So let's say that the .zip file was dropped onto the Desktop or
start
501 - 600 of 673 matches
Mail list logo
