On 09 avril 14:05, Steve Holden wrote:
Oleg Broytmann wrote:
On Thu, Apr 09, 2009 at 01:14:21PM -0400, Tony Nelson wrote:
I use MySQL, but sort of intend to learn PostgreSQL. I didn't know that
PostgreSQL has no real support for BLOBs.
I think it has - BYTEA data type.
But the
gl...@divmod.com wrote:
On 03:21 am, ncogh...@gmail.com wrote:
Given that json is a wire protocol, that sounds like the right approach
for json as well. Once bytes-everywhere works, then a text API can be
built on top of it, but it is difficult to build a bytes API on top of a
text one.
I
Guido van Rossum wrote:
Just to add some skepticism, has anyone done any kind of
instrumentation of bzr start-up behavior? IIRC every time I was asked
to reduce the start-up cost of some Python app, the cause was too many
imports, and the solution was either to speed up import itself (.pyc
On Thu, 2009-04-09 at 21:26 -0700, Guido van Rossum wrote:
Just to add some skepticism, has anyone done any kind of
instrumentation of bzr start-up behavior?
We sure have. 'bzr --profile-imports' reports on the time to import
different modules (both cumulative and individually).
We have a
glyph at 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.
Robert Collins robert.collins at 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
On Fri, 2009-04-10 at 11:52 +, Antoine Pitrou wrote:
Robert Collins robert.collins at 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,
2009/4/10 Nick Coghlan ncogh...@gmail.com:
gl...@divmod.com wrote:
On 03:21 am, ncogh...@gmail.com wrote:
Given that json is a wire protocol, that sounds like the right approach
for json as well. Once bytes-everywhere works, then a text API can be
built on top of it, but it is difficult to
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.
I don't think this can be
Guido van Rossum wrote:
On Wed, Apr 8, 2009 at 9:31 PM, Michele Simionato
michele.simion...@gmail.com wrote:
Then perhaps you misunderstand the goal of the decorator module.
The raison d'etre of the module is to PRESERVE the signature:
update_wrapper unfortunately *changes* it.
When
I wanted to cut Python 2.6.2 final tonight, but for family reasons I
won't be able to do so until Monday. Please be conservative in any
commits to the 2.6 branch between now and then.
bugs.python.org is apparently down right now, but I set issue 5724 to
release blocker for 2.6.2. This is
Neil Hodgson wrote:
cmake does not produce relative paths in its generated make and
project files. There is an option CMAKE_USE_RELATIVE_PATHS which
appears to do this but the documentation says:
This option does not work for more complicated projects, and
relative paths are used when
Guido van Rossum wrote:
On Wed, Apr 8, 2009 at 9:31 PM, Michele Simionato
But I feel strongly about
the possibility of being able to preserve (not change!) the function
signature.
That could be added to functools if enough people want it.
No objection in principle here - it's just hard to
John Arbash Meinel wrote:
Not as big of a difference as I thought it would be... But I bet if
there was a way to put the random shuffle in the inner loop, so you
weren't accessing the same identical 25k keys internally, you might get
more interesting results.
You can prepare a few random
Robert Collins wrote:
Certainly, import time is part of it:
robe...@lifeless-64:~$ python -m timeit -s 'import sys; import
bzrlib.errors' del sys.modules['bzrlib.errors']; import bzrlib.errors
10 loops, best of 3: 18.7 msec per loop
(errors.py is 3027 lines long with 347 exception
On Apr 9, 2009, at 10:38 PM, Barry Warsaw wrote:
So, what I'm really asking is this. Let's say you agree that there
are use cases for accessing a header value as either the raw encoded
bytes or the decoded unicode.
As I said in the thread having nearly the same exact discussion on web-
Paul Moore writes:
On the other hand, further down in the document:
3. Encoding
JSON text SHALL be encoded in Unicode. The default encoding is
UTF-8.
Since the first two characters of a JSON text will always be ASCII
characters [RFC0020], it is possible to
On Fri, Apr 10, 2009 at 8:38 AM, Stephen J. Turnbull step...@xemacs.org wrote:
Paul Moore writes:
On the other hand, further down in the document:
3. Encoding
JSON text SHALL be encoded in Unicode. The default encoding is
UTF-8.
Since the first two
(3) The default transfer encoding syntax is UTF-8.
Notice that the RFC is partially irrelevant. It only applies
to the application/json mime type, and JSON is used in various
other protocols, using various other encodings.
I think it's a bad idea for any of the core
JSON API to accept or
Barry Warsaw ba...@python.org wrote:
In that case, we really need the
bytes-in-bytes-out-bytes-in-the-chewy-
center API first, and build things on top of that.
Yep.
Bill
___
Python-Dev mailing list
Python-Dev@python.org
On Apr 10, 2009, at 1:19 AM, gl...@divmod.com wrote:
On 02:38 am, ba...@python.org wrote:
So, what I'm really asking is this. Let's say you agree that there
are use cases for accessing a header value as either the raw
encoded bytes or the decoded unicode. What should this return:
On Thu, 2009-04-09 at 22:38 -0400, Barry Warsaw wrote:
On Apr 9, 2009, at 11:55 AM, Daniel Stutzbach wrote:
On Thu, Apr 9, 2009 at 6:01 AM, Barry Warsaw ba...@python.org wrote:
Anyway, aside from that decision, I haven't come up with an elegant
way to allow /output/ in both bytes and
On Apr 9, 2009, at 11:41 PM, Tony Nelson wrote:
At 22:38 -0400 04/09/2009, Barry Warsaw wrote:
...
So, what I'm really asking is this. Let's say you agree that there
are use cases for accessing a header value as either the raw encoded
bytes or the decoded unicode. What should this return:
On Apr 9, 2009, at 11:59 PM, Tony Nelson wrote:
Thinking about this stuff makes me nostalgic for the sloppy happy
days
of Python 2.x
You now have the opportunity to finally unsnarl that mess. It is
not an
insurmountable opportunity.
No, it's just a full time job wink. Now where did I
On Apr 10, 2009, at 1:22 AM, Stephen J. Turnbull wrote:
Those objects have headers and payload. The payload can be of any
type, though I think it generally breaks down into strings for
text/
* types and bytes for anything else (not counting multiparts).
*sigh* Why are you back-tracking?
On approximately 4/10/2009 9:56 AM, came the following characters from
the keyboard of Barry Warsaw:
On Apr 10, 2009, at 1:19 AM, gl...@divmod.com wrote:
On 02:38 am, ba...@python.org wrote:
So, what I'm really asking is this. Let's say you agree that there
are use cases for accessing a
Glenn Linderman wrote:
On approximately 4/10/2009 9:56 AM, came the following characters from
the keyboard of Barry Warsaw:
On Apr 10, 2009, at 1:19 AM, gl...@divmod.com wrote:
On 02:38 am, ba...@python.org wrote:
So, what I'm really asking is this. Let's say you agree that there
are use
Martin v. Löwis writes:
(3) The default transfer encoding syntax is UTF-8.
Notice that the RFC is partially irrelevant. It only applies
to the application/json mime type, and JSON is used in various
other protocols, using various other encodings.
Sure. That's their problem. In
On Apr 10, 2009, at 2:00 PM, Glenn Linderman wrote:
If one name has to be longer than the other, it should be the bytes
version. Real user code is more likely to want to use the text
version, and hopefully there will be more of that type of code than
implementations using bytes.
I'm not
On Apr 10, 2009, at 2:06 PM, Michael Foord wrote:
Shouldn't headers always be text?
/me weeps
PGP.sig
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python-Dev@python.org
Shouldn't this thread move lock stock and .signature to email-sig?
Barry Warsaw writes:
It does seem to make sense to think about headers as text header
names and text header values.
I disagree. IMHO, structured header types should have object values,
and something like
Bill Janssen writes:
Barry Warsaw ba...@python.org wrote:
In that case, we really need the
bytes-in-bytes-out-bytes-in-the-chewy-
center API first, and build things on top of that.
Yep.
Uh, I hate to rain on a parade, but isn't that how we arrived at the
*current* email
At 06:52 PM 4/10/2009 +1000, Nick Coghlan wrote:
This problem (slow application startup times due to too many imports at
startup, which can in turn can be due to top level imports for library
or framework functionality that a given application doesn't actually
use) is actually the main reason I
On Apr 10, 2009, at 3:06 PM, Stephen J. Turnbull wrote:
Bill Janssen writes:
Barry Warsaw ba...@python.org wrote:
In that case, we really need the
bytes-in-bytes-out-bytes-in-the-chewy-
center API first, and build things on top of that.
Yep.
Uh, I hate to rain on a parade, but isn't that
On Fri, Apr 10, 2009, Barry Warsaw wrote:
On Apr 10, 2009, at 2:06 PM, Michael Foord wrote:
Shouldn't headers always be text?
/me weeps
/me hands Barry a hankie
--
Aahz (a...@pythoncraft.com) * http://www.pythoncraft.com/
Why is this newsgroup different from all other
Robert Brewer writes:
Syntactically, there's no sense in providing:
Message.set_header('Subject', 'Some text', encoding='utf-16')
...since you could more clearly write the same as:
Message.set_header('Subject', 'Some text'.encode('utf-16'))
Which you now must *parse* and
Hi all,
this year we have 10-12 GSoC applications that I've put in the relevant
to core Python development category. These projects, if mentors etc
are found, are *guaranteed* a slot under the PSF GSoC umbrella. As
backup GSoC admin and general busybody, I've taken on the work of
coordinating
On Fri, Apr 10, 2009 at 5:38 PM, C. Titus Brown c...@msu.edu wrote:
Hi all,
this year we have 10-12 GSoC applications that I've put in the relevant
to core Python development category. These projects, if mentors etc
are found, are *guaranteed* a slot under the PSF GSoC umbrella. As
backup
On Fri, Apr 10, 2009 at 05:53:23PM -0300, Guilherme Polo wrote:
-
- IDLE/Tkinter patch integration improvement -- deal with ~120 tracker
- ? ? ? ?issues relating to IDLE and Tkinter.
-
-
- Is it important, for the discussion, to mention that it also involves
- testing this area (idle and
gl...@divmod.com wrote:
On 03:21 am, ncogh...@gmail.com wrote:
Barry Warsaw wrote:
I don't know whether the parameter thing will work or not, but you're
probably right that we need to get the bytes-everywhere API first.
Given that json is a wire protocol, that sounds like the right
Well, I think Numpy is of huge importance to a major Python user segment,
the scientific community. I don't know if that makes it 'core', but I
strongly agree that it's important.
Better testing is always useful, and more core, but IMO less important.
-T
On Sat, Apr 11, 2009 at 6:38 AM, C. Titus
On Fri, Apr 10, 2009 at 6:02 PM, C. Titus Brown c...@msu.edu wrote:
On Fri, Apr 10, 2009 at 05:53:23PM -0300, Guilherme Polo wrote:
-
- IDLE/Tkinter patch integration improvement -- deal with ~120 tracker
- ? ? ? ?issues relating to IDLE and Tkinter.
-
-
- Is it important, for the
2009/4/10 C. Titus Brown c...@msu.edu:
2x improve testing tools for py3k -- variously focus on improving test
coverage and testing wrappers.
One proposes to provide a nice wrapper to make nose and py.test
capable of running the regrtests, which (with no change to
On Fri, Apr 10, 2009 at 4:38 PM, C. Titus Brown c...@msu.edu wrote:
[megasnip]
roundup VCS integration / build tools to support core development --
a single student proposed both of these and has received some
support. See http://slexy.org/view/s2pFgWxufI for details.
From the
Nick Coghlan wrote:
I sometimes wish for a nice, solid lazy
module import mechanism that manages to avoid the potential deadlock
problems created by using import statements inside functions.
I created an ad-hoc one of these for PyGUI recently.
I can send you the code if you're interested.
I
Paul Moore wrote:
3. Encoding
JSON text SHALL be encoded in Unicode. The default encoding is
UTF-8.
This is at best confused (in my utterly non-expert opinion :-)) as
Unicode isn't an encoding...
I'm inclined to agree. I'd go further and say that if JSON
is really mean to be a text
On Fri, Apr 10, 2009 at 12:04 PM, Barry Warsaw ba...@python.org wrote:
On Apr 10, 2009, at 3:06 PM, Stephen J. Turnbull wrote:
Bill Janssen writes:
Barry Warsaw ba...@python.org wrote:
In that case, we really need the
bytes-in-bytes-out-bytes-in-the-chewy-
center API first, and build
Folks, I'm going off-line for a week to enjoy a family vacation. When
I come back I'll probably just archive most email unread, so now's
your chance to add braces to the language. :-)
Not-yet-retiring-ly y'rs,
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
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.
What is the 'bytes support' issue for json? Is it about content within
a json text? Or about the transport format of a json text?
The
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello everybody. My name is Thiago and currently I'm working as a
teacher in a high school in Brazil. I have plans to offer in the
school a programming course to the students, but I had some problems
to find a good langüage. As a Python programmer, I
[Dropping email sig]
On 11/04/2009 1:06 PM, Martin v. Löwis wrote:
However, I really think that this question cannot be answered by
reading the RFC. It should be answered by verifying how people use
the json library in 2.x.
In the absence of anything more formal, here are 2 anecdotes:
* The
It appears to be a simple change, but strangely, I'm not being able to
perform it. I already made correct modifications in Grammar/Grammar
file, the new keywords already appear in Lib/keyword.py and I also
changed the function validate_comp_op in Modules/parsermodule.c:
static int
I'm personally leaning slightly towards strings, putting the burden on
bytes-users of json to explicitly use the appropriate encoding, even in
cases where it *must* be utf8. On the other hand, I'm too lazy to dig
back through this large thread, but I seem to recall a suggestion that
using
53 matches
Mail list logo
