Mark Dickinson gmail.com> writes:
>
> On Wed, Apr 8, 2009 at 7:13 AM, John Barham gmail.com> wrote:
> > If you play around a bit it becomes clear that what set.pop() returns
> > is independent of the insertion order:
>
> It might look like that, but I don't think this is
> true in general (at l
Hello,
We're in the process of forward-porting the recent (massive) json updates to
3.1, and we are also thinking of dropping remnants of support of the bytes type
in the json library (in 3.1, again). This bytes support almost didn't work at
all, but there was a lot of C and Python code for it nev
Martin v. Löwis v.loewis.de> writes:
>
> What does Bob Ippolito think about this change? IIUC, he considers
> simplejson's speed one of its primary advantages, and also attributes it
> to the fact that he can parse directly out of byte strings, and marshal
> into them (which is important, as you
Guido van Rossum python.org> writes:
>
> I'm kind of surprised that a serialization protocol like JSON wouldn't
> support reading/writing bytes (as the serialized format -- I don't
> care about having bytes as values, since JavaScript doesn't have
> something equivalent AFAIK, and hence JSON does
Dirkjan Ochtman ochtman.nl> writes:
>
> The RFC states
> that JSON-text = object / array, meaning "loads" for '"hi"' isn't
> strictly valid.
Sure, but then:
>>> json.loads('[]')
[]
>>> json.loads(u'[]'.encode('utf16'))
Traceback (most recent call last):
File "", line 1, in
File "/home/anto
divmod.com> writes:
>
> In email's case this is true, but in JSON's case it's not. JSON is a
> format defined as a sequence of code points; MIME is defined as a
> sequence of octets.
Another to look at it is that JSON is a subset of Javascript, and as such is
text rather than bytes.
Regards
Robert Collins canonical.com> writes:
>
> (errors.py is 3027 lines long with 347 exception classes).
347 exception classes? Perhaps your framework is over-engineered.
Similarly, when using a heavy Web framework, reloading a Web app can take
several seconds... but I won't blame Python for that.
Martin v. Löwis v.loewis.de> writes:
>
> Not sure whether it would be *significantly* faster, but yes, Bob wrote
> an accelerator for parsing out of a byte string to make it really fast;
> IIRC, he claims that it is faster than pickling.
Isn't premature optimization the root of all evil?
Beside
Mart Sõmermaa gmail.com> writes:
>
> Proposal: add add_query_params() for appending query parameters to an URL to
urllib.parse and urlparse.
Is there anything to /remove/ a query parameter?
___
Python-Dev mailing list
Python-Dev@python.org
http://mai
Mart Sõmermaa gmail.com> writes:
>
> On Mon, Apr 13, 2009 at 12:56 AM, Antoine Pitrou pitrou.net>
wrote:
> Mart Sõmermaa gmail.com> writes:
> >
> > Proposal: add add_query_params() for appending query parameters to an URL
to
> urllib.parse and urlparse.
> I
Michael Foord voidspace.org.uk> writes:
>
> Weird or not, is there actually a *need* to remove query parameters?
Say you are filtering or sorting data based on some URL parameters. If the user
wants to remove one of those filters, you have to remove the corresponding query
parameter.
Regards
A
Bob Ippolito redivi.com> writes:
>
> The output of json/simplejson dumps for Python 2.x is either an ASCII
> bytestring (default) or a unicode string (when ensure_ascii=False).
> This is very practical in 2.x because an ASCII bytestring can be
> treated as either text or bytes in most situations,
Mark Dickinson gmail.com> writes:
>
> But I'd expect that there are already similar issues
> with a 'fat' build of py3k on OS X. After all, there's
> already a 'WORDS_BIGENDIAN' in pyconfig.h.in. I
> don't know where this is used.
It's used e.g. in unicode encoding/decoding, and in the IO lib.
Jeroen Ruigrok van der Werven in-nomine.org> writes:
>
> This got posted on the Unicode list, does it seem interesting for Python
> itself, the UTF-8 to UTF-16 transcoding might be?
>
> http://bjoern.hoehrmann.de/utf-8/decoder/dfa/
If you have some time on your hands, you could try benchmarking
Mark Dickinson gmail.com> writes:
>
> Okay, I think I might have fixed up the float endianness detection for
> universal builds on OS X. Ned, any chance you could give this
> another try with an updated version of the py3k-short-float-repr branch?
If this approach is sane, could it be adopted f
Mark Dickinson gmail.com> writes:
>
> > Has anyone tested a recent py3k using universal builds? Do all tests pass?
>
> Do you know the right way to create a universal build?
Not at all, sorry.
Regards
Antoine.
___
Python-Dev mailing list
Python-D
Lisandro Dalcin gmail.com> writes:
>
> However, your original question is still valid ... Why a binary read()
> returns an immutable type?
Because bytes is the standard type for holding binary data. Bytearray should
only be used when there's a real, measured performance advantage doing so
(which
Paul Moore gmail.com> writes:
>
> Oh, certainly! But in the absence of "intuitive", I've found in the
> past that "standardised" is often better than nothing (For
> example, I use Oracle's add_months function fairly often - it's not
> perfect, and not always intuitive, but at least it's well-def
Jess Austin gmail.com> writes:
>
> What other behavior options besides "last-valid-day-of-the-month"
> would you like to see?
IMHO, the question is rather what the use case is for the behaviour you are
proposing. In which kind of situation is it acceptable to turn 31/2 silently
into 29/2?
___
Jess Austin gmail.com> writes:
>
> I have worked in utility/telecom billing, and needed to examine large
> numbers of invoice dates, fulfillment dates, disconnection dates,
> payment dates, collection event dates, etc. There would often be
> particular rules for the relationships among these dat
James Y Knight fuhm.net> writes:
>
> It's a human-interface operation, and as such, everyone (ahem) "knows
> what it means" to say "2 months from now", but the details don't
> usually have to be thought about too much.
I don't think it's true. When you say "2 months from now", some people wi
Bill Janssen parc.com> writes:
>
> Or even better, stop trying to use a mapping, and just make the "params"
> value a list of (name, value) pairs.
You can even accept both a list of (name, value) pairs /and/ some **kwargs, like
the dict constructor does. It would be a pity to drop the user-frien
Bill Janssen parc.com> writes:
>
> This whole discussion seems a bit "rare and obscure" to me. I've built
> URLs for years without this method, and never felt the lack. What bugs me
> is the lack of a way to build multipart-formdata payloads, the only standard
> way to send non-Latin1 strings a
Bill Janssen parc.com> writes:
>
> ``The content type "application/x-www-form-urlencoded" is inefficient
> for sending large quantities of binary data or text containing non-ASCII
> characters.
The fact that it's "inefficient" (i.e. takes more bytes than an optimal encoding
scheme would) doesn't
Bill Janssen parc.com> writes:
>
> Sure. But nowhere does a spec say that this page charset should be used
> in sending the values of a FORM using application/x-www-form-urlencoded
> in a new HTTP request. It's just a convention some browsers use.
Let's call it a de facto standard then. A beha
Bill Janssen parc.com> writes:
>
> Sure. And if HTTP was all about browsers keying off pages, that would
> be fine with me. But it's not. HTTP is used in lots of places where
> there are no browsers;
I'm sorry, I don't follow you. The fact that something else than a browser makes
the request
Dirkjan Ochtman ochtman.nl> writes:
>
> As a hg developer, I have to concur. Keeping bytes-based APIs intact
> would make porting hg to py3k much, much easier. You may be able to
> imagine that dealing with paths correctly cross-platform on a VCS is a
> major PITA, and py3k is currently not he
Aahz pythoncraft.com> writes:
>
> The part that I haven't seen clearly addressed so far is what happens
> when disks get mounted across OSes (e.g. NFS).
Unless there's some kind of native NFS API for file access, it is hopelessly out
of scope for Python. We use whatever the C library exports to
Stephen J. Turnbull xemacs.org> writes:
>
> Well, the problem is that both parts are false. If you didn't start
> with a valid string in a known encoding, you shouldn't treat it as
> characters because it's not. Hand it to a careful API, and you'll get
> an Exception raised in your face.
Which
Raymond Hettinger rcn.com> writes:
>
> Would it make sense to provide a default ordering whenever the types are
> the same?
This doesn't work when they are not the same :-)
Instead, you could make the decorating a bit more sophisticated:
decorated = [(key, id(value), value) for key, value in
Paul Moore gmail.com> writes:
> But those
> people are also the *least* likely people to contribute on an
> English-speaking list, I guess (Sincere apologies if everyone but
> me on this list happens to actually be fluent English-speaking
> Russians )
Actually, we're all Finnish.
Regards,
Ånto
Stephen J. Turnbull xemacs.org> writes:
>
> If
> you see a broken encoding once, you're likely to see it a million times
> (spammers have the most broken software) or maybe have it raise an
> unhandled Exception a dozen times (in rate of using busted software,
> the spammers are closely followed
Damien Diederen crosstwine.com> writes:
>
> I couldn't figure out a way to get rid of it short of multi-#including
> "templates" and playing with the C preprocessor, however, and have the
> nagging feeling the latter would be frowned upon by the maintainers.
>
> There is a precedent with xmltok.
Stephen J. Turnbull xemacs.org> writes:
>
> I hate to break it to you, but most stages of mail processing have
> very little to do with SMTP. In particular, processing MIME
> attachments often requires dealing with file names.
AFAIK, the file name is only there as an indication for the user whe
Stephen J. Turnbull xemacs.org> writes:
>
> Excuse me, but I can't see a scheme that encodes bytes as Unicodes but
> only sometimes as a "clean separation".
Yet it is. Filenames are all unicode, without exception, and there's no implicit
conversion to bytes. That's a clean separation.
> So what
Jeroen Ruigrok van der Werven in-nomine.org> writes:
>
> So on medium and large datasets the decoder of Bjoern is very interesting,
> but the tiny case (just Bjoern's name) is quite a tad bit slower. The other
> cases seems more typical of what the average use in Python would be.
Keep in mind wh
Simon Cross gmail.com> writes:
>
> $ touch $'\xFF\xAA\xFF'
> $ vi $'\xFF\xAA\xFF'
> $ egrep foo $'\xFF\xAA\xFF'
>
> All worked fine from my Bash shell with locale encoding set to UTF-8.
The PEP is precisely about making py3k able to better handle these files (right
now os.listdir() doesn't retu
Paul Moore gmail.com> writes:
>
> I've yet to hear anyone claim that they would have an actual problem
> with a specific piece of code they have written.
Yep, that's the problem. Lots of theoretical problems noone has ever encountered
brought up against a PEP which resolves some actual problems
Thomas Breuel gmail.com> writes:
>
> How can you bring up practical problems against something that hasn't been
implemented?
The PEP is simple enough that you can simulate its effect by manually computing
the resulting unicode string for a hypothetical broken filename. Several people
have alread
Hrvoje Niksic avl.com> writes:
>
> "Should be considered" or "will be considered"? Python 3.0's UTF-8
> decoder happily accepts it and returns u'\udcff':
>
> >>> b'\xed\xb3\xbf'.decode('utf-8')
> '\udcff'
Yes, there is already a bug entry for it:
http://bugs.python.org/issue3672
I think we
Thomas Breuel gmail.com> writes:
>
> And, in fact, Windows Vista happily creates files with malformed UTF-16
encodings, and os.listdir() happily returns them.
The PEP won't change that, so what's the problem exactly?
> Under your proposal, passing the output from a correctly implemented file
s
Thomas Breuel gmail.com> writes:
>
> The error checking isn't necessarily deficient. For example, a safe and
legitimate thing to do is for third party libraries to throw a C++ exception,
raise a Python exception, or delete the half surrogate.
Do you have any concrete examples of this behaviour?
Thomas Breuel gmail.com> writes:
>
> So, I created some ISO8859-15 and ISO8859-8 encoded file names on a device,
plugged them into my Windows Vista machine, and fired up Python 3.0.First,
os.listdir("f:") returns a list of strings for those file names... but those
unicode strings are illegal.
So
Hello,
I don't think it has already posted to the list, apologies if it has.
Some Linux tools and vendors have been hit by an alleged "security hole" where
an embedded Python interpreter will prepend the current working directory to
sys.path as soon as PySys_SetArgv() is called by the embedding
Martin v. Löwis v.loewis.de> writes:
>
> Glenn Linderman suggested that the name "python-escape" is not very
> descriptive, so I've changed the name to "utf8b".
If the error handler is supposed to be used for codecs other than utf-8,
perhaps it should renamed something more generic, e.g. "surrog
Mark Dickinson gmail.com> writes:
>
> I *think* that third party code that's recompiled for 3.1 and that
> doesn't use the closure field will either just work, or will produce an
> easily-fixed compile error. Larry, does this sound right?
This doesn't sound right. The functions in the third par
Martin v. Löwis v.loewis.de> writes:
>
> > I don't personally care (I already was aware of UTF-8B), but there are
> > plenty of others who do.
>
> I think it is a fairly bad name, because it is easy to confuse it with
> the "surrogates" error handler (unless you suggest to rename that also).
I
MRAB mrabarnett.plus.com> writes:
>
> Judging by the existing names, I think that 'surrogate' would be
> reasonable. It already contains the meaning of substitute,
Only if you are a native English-speaker I suppose... For me it's just a
technical term denoting a certain class of unicode code poi
Stephen J. Turnbull xemacs.org> writes:
>
> Nothing is lost compared to 'strict', true, but under the PEP as it is
> a large fraction of Shift JIS and Big5 filenames cannot be read under
> ASCII-compatible file system encodings using 'utf8b'.
You should really be more specific. I'm not sure abou
Zooko Wilcox-O'Hearn zooko.com> writes:
>
> I'm not thinking of API compatibility as much as
> data compatibility -- someone used Python 3.1 to write down some
> filenames, and now a few years later they are trying to use the
> latest and greatest Python release to read those filenames...
Martin v. Löwis v.loewis.de> writes:
>
> Despite there being also an error handler called "surrogates".
People, perhaps we could end all the bikeshedding and call one of those handlers
"surrogates-pass" and the other "surrogates-escape", which sounds quite faithful
to what they actually /do/?
R
Martin v. Löwis v.loewis.de> writes:
> py> b'\xed\xa0\x80'.decode("utf-8","surrogates")
> '\ud800'
The point is, "surrogates" does not mean anything intuitive for an /error
handler/. You seem to be the only one who finds this name explicit enough,
perhaps because you chose it.
Most other handlers
Robert Kern gmail.com> writes:
>
> Since one may have more than one filesystem side-by-side, this can't be just
be
> a system-wide boolean somewhere. One would have to query the target directory
> for this information. I am not aware of the existence of code that does such
a
> query, though.
Hi,
> WPython is a re-implementation of (some parts of) Python, which drops
> support for bytecode in favour of a wordcode-based model (where a is word
> is 16 bits wide).
This is great!
Have you planned to port in to the py3k branch? Or, at least, to trunk?
Some opcode and VM optimizations have
Hi Cesare,
Cesare Di Mauro a-tono.com> writes:
>
> It was my idea too, but first I need to take a deep look at what parts
> of code are changed from 2.6 to 3.0.
> That's because I don't know how much work is required for this
> "forward" port.
If you have some questions or need some help, send
Hello,
Just food for thought here, but seeing how 3.1 is going to be a real featureful
schedule despite being released shortly after 3.0, wouldn't it make sense to
tighten future release planning a little? I was thinking something like doing a
major release every 12 months (rather than 18 to 24 mo
MRAB mrabarnett.plus.com> writes:
> Next you'll be saying that they should be named after years. Python
> 2010, anyone?
After py3k, that would be a regression ;)
cheers
Antoine.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.o
Martin v. Löwis v.loewis.de> writes:
>
> Such a schedule was initially used for the first 2.x releases. We then
> switched to 18 months because of user complaints: if releases come too
> frequently, the users are confused as to what release they should be
> using. Even 24 months is too frequently
MRAB mrabarnett.plus.com> writes:
>
> I'd probably say that TAB is s reasonable character to use, even though
> it's OK in POSIX; after all, should anyone really be using a control
> character in a filename?
Even newline characters are valid characters in a filename.
Why not go for the safe choi
Tarek Ziadé gmail.com> writes:
>
> But I was wondering if we should we add a LZW support in tarinfo,
> besides gzip and bzip2 ?
>
> Although this compression standard doesn't seem very used these days,
It would be more useful to add LZMA / xz support.
I don't think compress is used anymore, exc
Dirkjan Ochtman ochtman.nl> writes:
>
> It would seem to me that optimizations are likely to require data
> structure changes, for exactly the kind of core data structures that
> you're talking about locking down. But that's just a high-level view,
> I might be wrong.
Unless I'm misunderstanding
Ronald Oussoren mac.com> writes:
>
> Wouldn't it be possible to use a CSV file for this? That way we
> wouldn't have to invent yet another escaping mechanism and there's
> already good suppport for reading and writing CSV files in the
> standard library.
+1
We can even customize the delim
Jeffrey Yasskin gmail.com> writes:
>
> Over an 8-year lifetime for Python 3, Moore's law predicts that
> desktop systems will have up to 64 cores, at which point even the
> simplest GIL-removal strategy of making refcounts atomic will be a
> win, despite the 2x performance loss for a single threa
Jeffrey Yasskin gmail.com> writes:
>
> Sorry, I didn't mean to get into a GIL debate. All I'm saying is that
> I don't think changing the definition of Py_INCREF and Py_DECREF
> justifies going to Python 4.0, so I don't think their definitions
> should be part of the ABI. If that's not what the A
Jim Jewett gmail.com> writes:
>
> > The accessor macros to these fields (Py_REFCNT, Py_TYPE, Py_SIZE)
> > are also available to applications.
>
> There have been several experiments in memory management, ranging from
> not bothering to change the refcount on permanent objects like None,
> to pro
Aahz pythoncraft.com> writes:
>
> Forwarded to postmaster python.org -- if there's a problem with the
> checkins process itself, that won't help. Have you verified that the
> commits are landing? (I.e. is svn working properly?)
Yes, it is.
> Also, if you
> could double-check the python-chec
Hello,
> Hopefully I haven't wasted anyone's time - I just wanted to share what
> I see as a possibly substantial improvement to Python's core. let me
> know if you're interested in a patch to use for your own testing.
You should definitely open a bug entry in http://bugs.python.org. There, post
Martin v. Löwis v.loewis.de> writes:
>
> What about fairness? I don't know off-hand whether the GIL is
> fair,
According to a past discussion on this list, the current implementation isn't:
http://mail.python.org/pipermail/python-dev/2008-March/077814.html
(at least on the poster's system)
Rega
Brian de Alwis usask.ca> writes:
>
> It's a restriction required to obtain approval from our research
> ethics board -- people under 18 are considered to be minors in Canada
> and thus require the consent of their guardian to participate. Trying
> to obtain such permission for an anonymous
Clay McClure daemons.net> writes:
>
> Not only useful, but necessary. It seems there are few people on this
> list who understand IP well enough to realize how distorted ipaddr
> actually is.
Not having myself enough knowledge about IP routing and administration (although
I did happen to dissect
Terry Reedy udel.edu> writes:
>
> I watched and was greatly impressed by the video demo of Google's new
> Wave collaborative communication system. I believe it would/will help
> with some of the chronic problems we (and others) have.
I really don't think technical systems are an answer to soc
Hello
Only one of the py3k buildbots seems up:
http://www.python.org/dev/buildbot/3.x.stable/
cheers
Antoine.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/ma
Dirkjan Ochtman ochtman.nl> writes:
>
> http://www.python.org/dev/peps/pep-0385/
« [cloned branches] makes it easier to distinguish branches, at the expense of
requiring more disk space on the client. »
This is a bit misleading. Actually, by separating branches into distinct
repositories, you c
anatoly techtonik gmail.com> writes:
>
> 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 asynchr
Martin v. Löwis v.loewis.de> writes:
>
> > I've reported bug http://bugs.python.org/issue5924 some time ago and I
> > think it's a release blocker -- it seems easy to fix, but I don't have
> > time to actually submit a patch, so, I'd like to draw attention to it,
> > especially as a release candi
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 stream
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 a
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/.
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 s
Scott David Daniels Acm.Org> writes:
>
> MRAB wrote:
> > I was thinking along the lines of:
> > def peek(self, size=None, block=True)
> > If 'block' is True then return 'size' bytes, unless the end of the
> > file/stream is reached; if 'block' is False then return up to 'size'
> > bytes, with
Greg Ewing canterbury.ac.nz> writes:
>
> Anything else such as peek() that doesn't explicitly
> mention the buffer should fit into the abstraction
> properly.
peek() doesn't "fit into the abstraction" since it doesn't even exist on raw
streams.
While buffered and non-buffered streams have a rea
Neil Muller gmail.com> writes:
>
> The following issues in ElementTree still exist in the latest release
> candidate & all have small patches to fix the issue. Any chance of
> getting these in before the final release?
>
> http://bugs.python.org/issue6231
> http://bugs.python.org/issue6233
> htt
Benjamin Peterson python.org> writes:
>
> This policy applys to all public APIs.
applies?
> * The behavior of an API *must* not change between any two consecutive
> releases.
>
> * A feature cannot be removed without notice between any two consecutive
> releases.
By induction, this would me
divmod.com> writes:
>
> In order for any changes to be possible, there needs to be a clearly
> labeled mine-field: don't touch or depend on these things in your Python
> application or it *will* break every time Python is released.
I think the "frozen area" should be defined positively (explic
divmod.com> writes:
>
> This is a false dichotomy; for core developers, the list needs to be
> exhaustive. Everything that can change needs to be described as either
> compatible or incompatible.
How do you enumerate "everything that can change"? It does not look like a
finite set to me (but
Michael Foord voidspace.org.uk> writes:
>
> And this is why expressing a finite list of things we guarantee won't
> change is a virtually impossible task - unless one of you is
> volunteering to write an official spec for Python and its libraries...
Well, we *can* enumerate a list of things t
Benjamin Peterson python.org> writes:
>
> I mean that if you pass X and Y into a function and get Z in 2.6, then
> you should be able to get Z from passing X and Y in 2.7 even if
> there's a new argument that returns Z' if you pass True to it.
Well, except if returning Z rather than Z' was a bug
Hello,
> For better or for worse, I have created a patch against the py3k trunk
> which introduces a binary operator '@' as an alternative syntax for
> the new string formatting system introduced by PEP 3101 ("Advanced
> String Formatting"). [1]
While many people find the new format() tedious to
Maciej Fijalkowski gmail.com> writes:
>
> Is py3k branch even passing all tests on all buildbots all the time?
As much as other branches do (that is, not much, due to the flakiness of some of
the tests and the lack of buildbot maintenance).
> I don't think
> svn head is the right thing to look
Hello,
Tarek Ziadé gmail.com> writes:
>
> so I am mailing it here again, for a new round of feedback, if needed.
>
> - the pep : http://svn.python.org/projects/peps/trunk/pep-0376.txt
Some comments:
- the **MD5** hash of the file, encoded in hex. Notice that `pyc` and `pyo`
generated f
Sridhar Ratnakumar activestate.com> writes:
>
> On 09-06-23 02:57 AM, Nick Coghlan wrote:
> > Something like DistributionDirectoryMap should cover it.
> >
> > You could probably get away with shortening "Directory" to "Dir" in the
> > class names though:
> >
> > - Distribution
> > - ZippedDis
Filippo Battaglia email.it> writes:
>
> http://www.psp-ita.com/forum/viewtopic.php?t=28323&start=20
>
> from ndpsp import *
> x = time.clock ()
> for i in range(1000):
> pass
> print >> clock, "1.", time.clock()-t
First, it has been noted that your message would better be sent to python
Guido van Rossum python.org> writes:
>
> I noted an inconsistency: first you say that the RECORD file uses the
> excel dialect, but at the end of the same section you say it uses the
> default csv settings. Sounds like you need to delete one or the other.
If I remember correctly, the default csv
Nick Coghlan gmail.com> writes:
>
> I think is exchange actually a good reminder that the bar for acceptance
> of PEP 376 shouldn't be "Addresses every possible packaging issue we can
> come up with". That would be setting expectations far too high because
> packaging cross-platform is so messy.
Paul Moore gmail.com> writes:
>
> I have no answer here. But I think we need feedback from the people
> who will ultimately be building bdist_xxx formats - Debian packagers,
> people wrting alternate RPM builders, etc.
I think any bdist_xxx command which targets externally handled package format
Hi,
> There seem to be two places to plausibly introduce a change: py3k and
> trunk. Should I submit changes for trunk, py3k, or both? I tried
> asking in the initial feature request, but nobody replied, and I finally
> decided that I'd go for patching trunk in the interim.
Patches are usually
Hi,
I've added the release31-maint branch to the temporary Mercurial mirrors:
http://code.python.org/hg
Regards
Antoine.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.p
Curt Hagenlocher hagenlocher.org> writes:
>
> The OS has to provide a mechanism to enable execution for a particular
> region of memory. Under Windows, this is done by the VirtualProtect
> function.
More surprising is that Microsoft didn't whitelist their own toolchain.
__
Brett Cannon python.org> writes:
>
>
> I implemented get_filename() as specified in PEP 302 for importlib's source
and bytecode loaders and I was starting to create the ABC for importlib.abc,
but then I realized that perhaps the loader should live in runpy instead of
importlib.
>
> Putting the
Hi,
> I used mingw32 (stable distro) to build the psyco extension
> on top of standard python2.6, built with Visual Studio,
> and got weird crashes.
>
> The reason is in objimpl.h:
>
> typedef union _gc_head {
> struct {
> union _gc_head *gc_next;
> union _gc_he
2201 - 2300 of 4909 matches
Mail list logo
