On Jan 6, 2005, at 15:03, Bob Ippolito wrote:
On Jan 6, 2005, at 14:59, Ronald Oussoren wrote:
On 6-jan-05, at 14:04, Jack Jansen wrote:
On 6 Jan 2005, at 00:49, Martin v. Löwis wrote:
The "new" solution is basically to go back to the Unix way of
building an extension: link it against nothing and
>I'm considering a change to the csv module that could potentially break
>some obscure uses of the module (but CSV files usually quote, rather
>than escape, so the most common uses aren't effected).
>
>Currently, with a non-default escapechar='\\', input like:
>
>field one,field \
>two,fiel
On 7 Jan 2005, at 11:08, Bob Ippolito wrote:
10.3 or later. For older OSX releases (either because you build
Python on 10.2 or earlier, or because you've set
MACOSX_DEPLOYMENT_TARGET to a value of 10.2 or less) we use the old
behaviour of linking with "-framework Python".
Wouldn't it be better t
Andrew McNamara <[EMAIL PROTECTED]>:
>
[snip]
> Currently, with a non-default escapechar='\\', input like:
>
> field one,field \
> two,field three
>
> Returns:
>
> ["field one", "field \\\ntwo", "field three"]
>
> In the 2.5 series, I propose changing this to return:
>
> ["fiel
Andrew explains that in the CSV module, escape characters are not
properly removed.
Magnus writes:
> IMO this is the *only* reasonable behaviour. I don't understand why
> the escape character should be left in; this is one of the reason why
> UNIX-style colon-separated values don't work with the c
On 2005 Jan 07, at 14:45, Michael Chermside wrote:
Andrew explains that in the CSV module, escape characters are not
properly removed.
Magnus writes:
IMO this is the *only* reasonable behaviour. I don't understand why
the escape character should be left in; this is one of the reason why
UNIX-style
Bob Ippolito <[EMAIL PROTECTED]> writes:
> On Jan 6, 2005, at 8:17, Michael Hudson wrote:
>
>> Ilya Sandler <[EMAIL PROTECTED]> writes:
>>
>>> A problem:
>>>
>>> The current struct.unpack api works well for unpacking C-structures
>>> where
>>> everything is usually unpacked at once, but it
>>> bec
> Bob Ippolito <[EMAIL PROTECTED]> writes:
>> This is my ctypes-like attempt at a high-level interface for struct.
>> It works well for me in macholib:
>> http://svn.red-bean.com/bob/py2app/trunk/src/macholib/ptypes.py
Michael Hudson <[EMAIL PROTECTED]> writes:
>
> Unsurprisingly, that's fairly s
On Jan 7, 2005, at 9:33 AM, Thomas Heller wrote:
Bob Ippolito <[EMAIL PROTECTED]> writes:
This is my ctypes-like attempt at a high-level interface for struct.
It works well for me in macholib:
http://svn.red-bean.com/bob/py2app/trunk/src/macholib/ptypes.py
Michael Hudson <[EMAIL PROTECTED]> writes
Thomas Heller <[EMAIL PROTECTED]> writes:
>> Bob Ippolito <[EMAIL PROTECTED]> writes:
>
>>> This is my ctypes-like attempt at a high-level interface for struct.
>>> It works well for me in macholib:
>>> http://svn.red-bean.com/bob/py2app/trunk/src/macholib/ptypes.py
>
> Michael Hudson <[EMAIL PROT
Barry Warsaw wrote:
As an experiment, I just added a PEP topic to the python-checkins
mailing list. You could subscribe to this list and just select the PEP
topic (which matches the regex "PEP" in the Subject header or first few
lines of the body).
Give it a shot and let's see if that does the tri
On Fri, 2005-01-07 at 10:05, Nick Coghlan wrote:
> Barry Warsaw wrote:
> > As an experiment, I just added a PEP topic to the python-checkins
> > mailing list. You could subscribe to this list and just select the PEP
> > topic (which matches the regex "PEP" in the Subject header or first few
> > li
Title: RE: [Python-Dev] Re: Subscribing to PEP updates
[Barry Warsaw]
> As an experiment, I just added a PEP topic to the python-checkins
> mailing list. You could subscribe to this list and just select the PEP
> topic (which matches the regex "PEP" in the Subject header or first few
> line
[Andrew McNamara]
>> Also, review comments from Jeremy Hylton, 10 Apr 2003:
>>
>>I've been reviewing extension modules looking for C types that should
>>participate in garbage collection. I think the csv ReaderObj and
>>WriterObj should participate. The ReaderObj it contains a referen
Batista, Facundo wrote:
[Barry Warsaw]
> As an experiment, I just added a PEP topic to the python-checkins
> mailing list. You could subscribe to this list and just select the PEP
> topic (which matches the regex "PEP" in the Subject header or first few
> lines of the body).
>
> Give it a sh
On Jan 6, 2005, at 5:45 PM, Delaney, Timothy C (Timothy) wrote:
Well, there's my autosuper recipe you've seen before:
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/286195
which does basically what Philip descibes ...
You missed the most important part of the example -- the automatic
argu
Andrew> I'm considering a change to the csv module that could
Andrew> potentially break some obscure uses of the module (but CSV files
Andrew> usually quote, rather than escape, so the most common uses
Andrew> aren't effected).
I'm with the other respondents. This looks like a bu
Barry Warsaw wrote:
Please do (he says, hoping it works :).
Speaking of which. . . care to poke PEP 0 or one of the other PEP's? There's
probably a couple of PEP's which could be moved from 'Open' to 'Accepted' or
'Accepted' to 'Implemented' to try it out.
Cheers,
Nick.
--
Nick Coghlan | [EM
On Jan 6, 2005, at 12:13 PM, Guido van Rossum wrote:
So it has nothing to do with the new paradigm, just with backwards
compatibility. I appreciate those issues (more than you'll ever know)
but I don't see why you should try to discourage others from using the
new paradigm, which is what your artic
Today's Slashdot
(http://slashdot.org/articles/05/01/07/158236.shtml?tid=137) points to:
"The Free Lunch Is Over: A Fundamental Turn Toward Concurrency in
Software" by Herb Sutter at
"http://www.gotw.ca/publications/concurrency-ddj.htm";.
Is Python a suitable language for concurrent programmin
How's the merge going?
And if I haven't already said thanks, then, thanks for doing it!
Jeremy
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/pyth
On Jan 7, 2005, at 2:44 PM, Edward C. Jones wrote:
Is Python a suitable language for concurrent programming?
Depends on what you mean. Python is not very good for shared-memory
concurrent programming. (That is, threads). The library doesn't have
enough good abstractions for locks/synchronizatio
Jeremy Hylton <[EMAIL PROTECTED]> writes:
> How's the merge going?
Looks like it's done. I tagged ast-branch when I finished:
merged_from_MAIN_07JAN05
Right now I'm trying to get Python-ast.c to compile. It wasn't
modified by the merge, so there's some other issue.
> And if I haven't already
>
> From: [EMAIL PROTECTED] (Kurt B. Kaiser)
> Date: 2005/01/07 Fri PM 09:18:11 GMT
> To: python-dev@python.org
> Subject: Re: [Python-Dev] Re: [Python-checkins] python/dist/src/Python
> pythonrun.c, 2.161.2.15, 2.161.2.16
>
> Jeremy Hylton <[EMAIL PROTECTED]> writes:
>
> > How's the merg
On Fri, 07 Jan 2005 16:18:11 -0500, Kurt B. Kaiser <[EMAIL PROTECTED]> wrote:
> Looks like it's done. I tagged ast-branch when I finished:
>
> merged_from_MAIN_07JAN05
>
> Right now I'm trying to get Python-ast.c to compile. It wasn't
> modified by the merge, so there's some other issue.
I'm g
Jeremy Hylton <[EMAIL PROTECTED]> writes:
> ../Python/symtable.c:193: structure has no member named `st_tmpname'
>
> Do you see that?
Yeah, the merge eliminated it from the symtable struct in symtable.h.
You moved it to symtable_entry at rev 2.12 in MAIN :-)
I'll research it.
Apparently my buil
I will try to respond to all comments at once.
But first a clarification:
-I am not trying to design a high-level API on top of existing
struct.unpack and
-I am not trying to design a replacement for struct.unpack
(If I were to replace struct.unpack(), then I would probably go along
Ilya Sandler wrote:
item=unpack( "", rec, offset)
How about making offset a standard integer, and change the signature to return a
tuple when it is used:
item = unpack(format, rec) # Full unpacking
offset = 0
item, offset = unpack(format, rec, offset) # Partial unpacking
The second
[Ilya Sandler]
> I view struct module as a low-level (un)packing library on top on
which
> a more complex stuff can be built and I am simply suggesting a way to
> improve this low level functionality...
> > > We could have an optional offset argument for
> > >
> > > unpack(format, buffer, offset=No
> How about making offset a standard integer, and change the signature to
> return tuple when it is used:
> item, offset = unpack(format, rec, offset) # Partial unpacking
Well, it would work well when unpack results are assigned to individual
vars:
x,y,offset=unpack( "ii", rec, offset)
but
[EMAIL PROTECTED] (Kurt B. Kaiser) writes:
> [JH]
>> ../Python/symtable.c:193: structure has no member named `st_tmpname'
>>
>> Do you see that?
>
> Yeah, the merge eliminated it from the symtable struct in symtable.h.
> You moved it to symtable_entry at rev 2.12 in MAIN :-)
>
> I'll research it.
Ilya Sandler wrote:
How about making offset a standard integer, and change the signature to
return tuple when it is used:
item, offset = unpack(format, rec, offset) # Partial unpacking
Well, it would work well when unpack results are assigned to individual
vars:
x,y,offset=unpack( "ii", rec, o
32 matches
Mail list logo
