Brett Cannon wrote:
> What is going in under python/ ? If it is what is currently
> /dist/src/, then great and the renaming of the repository works.
Just have a look yourself :-) Yes, this is dist/src.
> But if that is what src/ is going to be used for
This is nondist/src. Perhaps I should just
Nicholas Bastin wrote:
> It's a mature product. I would hope that that would count for
> something.
Sure. But so is subversion.
> I've had enough corrupted subversion repositories that I'm
> not crazy about the thought of using it in a production system.
I had the last corrupted repository with
Guido van Rossum wrote:
> I'm not sure if it works for all encodings, but if possible I'd like
> to extend the seeking semantics on text files: seek positions are byte
> counts, and the application should consider them as "magic cookies".
If the seek position is merely a number, it won't work for
On Aug 7, 2005, at 7:37 PM, Martin v. Löwis wrote:
> Guido van Rossum wrote:
>
>>> If stdin, stdout and stderr go to a terminal, there already is a
>>> default encoding (actually, there always is a default encoding on
>>> these, as it falls back to the system encoding if its not a
>>> terminal,
Guido van Rossum wrote:
>>If stdin, stdout and stderr go to a terminal, there already is a
>>default encoding (actually, there always is a default encoding on
>>these, as it falls back to the system encoding if its not a terminal,
>>or if the terminal's encoding is not supported or cannot be determ
On Sunday 07 August 2005 22:14, Guido van Rossum wrote:
> I think the INCREFs don't need to be documented because you don't have
> to worry about them -- they follow the normal pattern of reference
> counts: if you owned an object before passing it to PyTuple_Pack(),
> you still own it afterwar
On Sun, 2005-08-07 at 21:52, Nicholas Bastin wrote:
> I've had enough corrupted subversion repositories that I'm
> not crazy about the thought of using it in a production system. I
> know I'm not the only person with this experience. Sure, you can keep
> backups, and not really lose any work, bu
At 05:24 PM 8/7/2005 -0700, Guido van Rossum wrote:
>Hm. What would be the use case for using %s with binary, non-text data?
Well, I could see using it to write things like netstrings,
i.e. sock.send("%d:%s," % (len(data),data)) seems like the One Obvious Way
to write a netstring in today's Pyt
On Sat, Aug 06, 2005 at 06:56:39PM -0700, Guido van Rossum wrote:
> My first response to the PEP, however, is that instead of a new
> built-in function, I'd rather relax the requirement that str() return
> an 8-bit string
Do you have any thoughts on what the C API would be? It seems to me
that Py
> According to the source code, PyTuple_Pack returns a new reference (it
> calls PyTuple_New). It also Py_INCREF's all the objects in the new
> tuple. Is this unusual behavior?
No. That is how containers work. Look at PyBuild_Value() for
comparison.
> None of these added references are doc
On 8/7/05, Edward C. Jones <[EMAIL PROTECTED]> wrote:
> According to the source code, PyTuple_Pack returns a new reference (it
> calls PyTuple_New). It also Py_INCREF's all the objects in the new
> tuple. Is this unusual behavior? None of these added references are
> documented in the API Reference
On 8/7/05, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> I have placed a new version of the PEP on
>
> http://www.python.org/peps/pep-0347.html
>
> Changes to the previous version include:
>
> - add more rationale for using svn (atomic changesets,
> fast tags and branches)
>
> - changed conv
According to the source code, PyTuple_Pack returns a new reference (it
calls PyTuple_New). It also Py_INCREF's all the objects in the new
tuple. Is this unusual behavior? None of these added references are
documented in the API Reference Manual.
___
Py
On 8/7/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Brett Cannon wrote:
> > * SystemExit are the KeyboardInterrupt are the only exceptions *not*
> > inheriting from Exception
> > + CriticalException has been renamed TerminalException so it is
> > more inline with the idea that the exceptions a
On 8/7/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> VMError -- This is a new intermediate grouping so it won't break
> anything and it does bring together two exceptions relating them by
> source. However, I recommend against introducing this new group.
> Besides added yet another thing to r
On 8/4/05, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Nicholas Bastin wrote:
> > Perforce is a commercial product, but it can be had for free for
> > verified Open Source projects, which Python shouldn't have any problem
> > with. There are other problems, like you have to renew the agreement
Martin v. Löwis wrote:
> Donovan Baarda wrote:
>>What this means is SVN has no way of automatically identifying the
>>common version.
> If this is too painful, you can probably use subversion to store
> the relevant information. For example, you could define a custom
> property on the directory
[Guido]
> > My first response to the PEP, however, is that instead of a new
> > built-in function, I'd rather relax the requirement that str() return
> > an 8-bit string -- after all, int() is allowed to return a long, so
> > why couldn't str() be allowed to return a Unicode string?
[MAL]
> The pr
[Reinhold Birkenfeld]
> > FWIW, I've already drafted a patch for the former. It lets you write to
> > file.encoding and honors this when writing Unicode strings to it.
[Martin v L]
> I don't like that approach. You shouldn't be allowed to change the
> encoding mid-stream (except perhaps under very
[me]
> > a way to decide on a default encoding for stdin,
> > stdout, stderr.
[Martin]
> If stdin, stdout and stderr go to a terminal, there already is a
> default encoding (actually, there always is a default encoding on
> these, as it falls back to the system encoding if its not a terminal,
> or
> > Maybe in Py3K this could become
> >
> > raise ValueError("bloop"), tb
>
> The instantiation and bindings need to be done in one step without
> mixing two syntaxes. Treat this case the same as everything else:
>
> raise ValueError("blip", traceback=tb)
That requires PEP 344. I have some vagu
Donovan Baarda wrote:
> What this means is SVN has no way of automatically identifying the
> common version.
Ah, ok. That's true. It doesn't mean you can't do proper merging
with subversion - it only means that it is harder, as you need to
figure out the revision range that you want to merge.
If
On Sun, 7 Aug 2005, [ISO-8859-1] "Martin v. L?wis" wrote:
> Ilya Sandler wrote:
> > Should pdb's next command accept an optional numeric argument? It would
> > specify how many actual lines of code (not "line events")
> > should be skipped in the current frame before stopping,
> [...]
> > What
Martin v. Löwis wrote:
> Donovan Baarda wrote:
>
>>Yeah. IMHO the sadest thing about SVN is it doesn't do branch/merge
>>properly. All the other cool stuff like renames etc is kinda undone by
>>that. For a definition of properly, see;
>>
>>http://prcs.sourceforge.net/merge.html
>
>
> Can you ple
Ilya Sandler wrote:
> Should pdb's next command accept an optional numeric argument? It would
> specify how many actual lines of code (not "line events")
> should be skipped in the current frame before stopping,
[...]
> What do you think?
That would differ from gdb's "next ", which does "next" n
Anthony Baxter wrote:
> I should probably add that I'm not flagging that I think there's a problem
> here. I'm mostly urging caution - I hate having to cut brown-paper-bag
> releases . If possible, can the folks on c++-sig try this patch
> out and put their results in the patch discussion? If you'
Problem:
When the code contains list comprehensions (or for that matter any other
looping construct), the only way to get quickly through this code in pdb
is to set a temporary breakpoint on the line after the loop, which is
inconvenient..
There is a SF bug report #1248119 about this behavior.
> > How do you then supply a traceback to the raise statement?
>
> raise ValueError, ValueError("blah"), tb
>
> Maybe in Py3K this could become
>
> raise ValueError("bloop"), tb
The instantiation and bindings need to be done in one step without
mixing two syntaxes. Treat this case the same as
Michiel De Hoon wrote:
> Speaking of the five-patch-review-rule, about two months ago I reviewed five
> patches and posted a summary here in order to push patch #1049855. This patch
> is still waiting for a verdict (this is also my own fault, since I needed
> several iterations to get this patch st
> How do you then supply a traceback to the raise statement?
raise ValueError, ValueError("blah"), tb
Maybe in Py3K this could become
raise ValueError("bloop"), tb
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailin
Guido van Rossum <[EMAIL PROTECTED]> writes:
> On 8/6/05, A.M. Kuchling <[EMAIL PROTECTED]> wrote:
>> PEP 8 doesn't express any preference between the
>> two forms of raise statements:
>> raise ValueError, 'blah'
>> raise ValueError("blah")
>>
>> I like the second form better, because if the exce
Martin v. Löwis wrote:
> M.-A. Lemburg wrote:
>
>>BTW, in one of your replies I read that you had a problem with
>>how cvs2svn handles trunk, branches and tags. In reality, this
>>is no problem at all, since Subversion is very good at handling
>>moves within the repository: you can easily change t
Donovan Baarda wrote:
> Yeah. IMHO the sadest thing about SVN is it doesn't do branch/merge
> properly. All the other cool stuff like renames etc is kinda undone by
> that. For a definition of properly, see;
>
> http://prcs.sourceforge.net/merge.html
Can you please elaborate? I read the page, and
I have placed a new version of the PEP on
http://www.python.org/peps/pep-0347.html
Changes to the previous version include:
- add more rationale for using svn (atomic changesets,
fast tags and branches)
- changed conversion procedure to a single repository, with
some reorganization. See
Fernando Perez wrote:
> I know Joe was in contact with the SVN devs to work on this, so perhaps he's
> using a patched version of cvs2svn, I simply don't know. But I mention it in
> case it proves useful to the python.org conversion.
Thanks for the pointer. It turns out that I could resolve all m
Jeff Rush wrote:
> BTW, re SSH access on python.org, using Apache's SSL support re https would
> provide as good of security without the risk of giving out shell accounts.
> SSL would encrypt the link and require a password or permit cert auth
> instead, same as SSH. Cert admin needn't be hard
Phillip J. Eby wrote:
> Yeah, in my use of SVN I find that this is more theoretical than actual
> for certain use cases. You can see the history of a file including the
> history of any file it was copied from. However, if you want to try to
> look at the whole layout, you can't easily get to the
M.-A. Lemburg wrote:
> BTW, in one of your replies I read that you had a problem with
> how cvs2svn handles trunk, branches and tags. In reality, this
> is no problem at all, since Subversion is very good at handling
> moves within the repository: you can easily change the repository
> layout after
Guido van Rossum wrote:
> My first response to the PEP, however, is that instead of a new
> built-in function, I'd rather relax the requirement that str() return
> an 8-bit string -- after all, int() is allowed to return a long, so
> why couldn't str() be allowed to return a Unicode string?
The pr
Reinhold Birkenfeld wrote:
> FWIW, I've already drafted a patch for the former. It lets you write to
> file.encoding and honors this when writing Unicode strings to it.
I don't like that approach. You shouldn't be allowed to change the
encoding mid-stream (except perhaps under very specific circum
Guido van Rossum wrote:
> The main problem for a smooth Unicode transition remains I/O, in my
> opinion; I'd like to see a PEP describing a way to attach an encoding
> to text files, and a way to decide on a default encoding for stdin,
> stdout, stderr.
If stdin, stdout and stderr go to a terminal
Brett Cannon wrote:
> * SystemExit are the KeyboardInterrupt are the only exceptions *not*
> inheriting from Exception
> + CriticalException has been renamed TerminalException so it is
> more inline with the idea that the exceptions are meant to terminate
> the interpreter, not that they are mo
Raymond Hettinger wrote:
> FIBTN (flat-is-better-than-nested) -- This bit of Zen carries extra
> significance for the exception hierarchy. The core issue is that
> exceptions are NOT inherently tree-structured. Each may ultimately
> carry its own set of meaningful attributes and those tend to not
VMError -- This is a new intermediate grouping so it won't break
anything and it does bring together two exceptions relating them by
source. However, I recommend against introducing this new group.
Besides added yet another thing to remember, it violates
Flat-Is-Better-Than-Nested (see FIBTN below
Guido van Rossum wrote:
> The main problem for a smooth Unicode transition remains I/O, in my
> opinion; I'd like to see a PEP describing a way to attach an encoding
> to text files, and a way to decide on a default encoding for stdin,
> stdout, stderr.
FWIW, I've already drafted a patch for the
45 matches
Mail list logo
