On Fri, Apr 10, 2009 at 9:58 PM, Harry (Thiago Leucz Astrizi)
wrote:
>
> 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
> 2x "keyring package" -- see
> http://tarekziade.wordpress.com/2009/03/27/pycon-hallway-session-1-a-keyring-library-for-python/.
> The poorer one of these will probably be axed unless Tarek gives it
> strong support.
I don't think these are good "core" projects. Even if the students come
up with
> 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
> usin
> 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
> va
[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:
* Th
-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 r
>> 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 te
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/)
_
On Fri, Apr 10, 2009 at 12:04 PM, Barry Warsaw wrote:
> On Apr 10, 2009, at 3:06 PM, Stephen J. Turnbull wrote:
>
>> Bill Janssen writes:
>>>
>>> Barry Warsaw wrote:
>>>
In that case, we really need the
bytes-in-bytes-out-bytes-in-the-chewy-
center API first, and build things on to
On Friday, 10 April 2009 at 15:05, P.J. Eby wrote:
> 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 appli
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 f
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 d
On Fri, Apr 10, 2009 at 4:38 PM, C. Titus Brown 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 listed web
On Fri, Apr 10, 2009 at 06:05:02PM -0500, Benjamin Peterson wrote:
-> 2009/4/10 C. Titus Brown :
-> > 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
2009/4/10 C. Titus Brown :
> 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
> regrt
On Fri, Apr 10, 2009 at 6:02 PM, C. Titus Brown 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
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. Titu
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 approa
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 (i
On Fri, Apr 10, 2009 at 5:38 PM, C. Titus Brown 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 GSoC
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
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 *pars
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 o
On Apr 10, 2009, at 3:06 PM, Stephen J. Turnbull wrote:
Bill Janssen writes:
Barry Warsaw 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 a
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 s
Bill Janssen writes:
> Barry Warsaw 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 package?
_
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 lik
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
http://mail.python.org/mailman/listinfo/py
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
"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.
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 case
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 header
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 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 . Now where did I put
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:
m
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 wrote:
> > Anyway, aside from that decision, I haven't come up with an elegant
> > way to allow /output/ in both bytes and strings (in
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:
>>> mes
Barry Warsaw 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
http://mail.python.org/mailman/listinfo/py
> (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 pr
On Fri, Apr 10, 2009 at 8:38 AM, Stephen J. Turnbull 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 char
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 po
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-
sig
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
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
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
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 poss
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
Guido van Rossum wrote:
On Wed, Apr 8, 2009 at 9:31 PM, Michele Simionato
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 confronted with a library which I d
>> 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
On Fri, 2009-04-10 at 11:52 +, Antoine Pitrou wrote:
> 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
2009/4/10 Nick Coghlan :
> 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 b
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.
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
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 la
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
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 on
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.
57 matches
Mail list logo
