On 5/1/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> then what should be the meaning of "continue" here? The finally
> block *eventually* needs to re-raise the exception. When should
> that happen?
It should behave similarly to return and swallow the exception. In
your example this would resu
On Tuesday 02 May 2006 22:32, Guido van Rossum wrote:
> and '@deco').
Pronounced "at-deck-oh", @deco is an art-deco variant favored in "r"-deprived
regions.
-Fred
--
Fred L. Drake, Jr.
___
Python-Dev mailing list
Python-Dev@python.org
http://m
On 5/2/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > On 5/2/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
>
> > >make_person(=name, =age, =phone, =location)
> >
> > And even with Terry's use case quoted I can't make out what you meant
> > that to do.
>
> I meant it to do t
Guido van Rossum wrote:
> On 5/2/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> >make_person(=name, =age, =phone, =location)
>
> And even with Terry's use case quoted I can't make out what you meant
> that to do.
I meant it to do the same thing as
make_person(name=name, age=age, phone=phone
Don't worry. This isn't going to change. Someone please update PEP 3099.
On 5/2/06, Delaney, Timothy (Tim) <[EMAIL PROTECTED]> wrote:
> Josiah Carlson wrote:
>
> > for line in lines:
> > line = line.rstrip()
> > ...
>
> Exactly the use case I was thinking of (and one I used yes
Hello,
I saw the discussion about including the path type in the standard
library. As it turned out, I recently wrote a program which does quite
a lot of path manipulation. This caused me to think that the proposed
path module:
* Makes path manipulation significantly easier
* Can be improved.
Josiah Carlson wrote:
> for line in lines:
> line = line.rstrip()
> ...
Exactly the use case I was thinking of (and one I used yesterday BTW).
I'm -1 on *dis*allowing reusing a name bound in a for loop in any
construct i.e. +1 for the status quo.
Tim Delaney
Sorry to bother the list -- talin, mail to you is bouncing:
- The following addresses had permanent fatal errors -
<[EMAIL PROTECTED]>
- Transcript of session follows -
... while talking to viridia.org
>>> RCPT To:<[EMAIL PROTECTED]>
<<< 550 message to verify they are valid."
Guido van Rossum wrote:
> I've used a double leading underscore on the name. Works great for methods!
We discussed that. My main issue with that is that it's possible/likely
that all arguments should be positional by default, should they all then
begin with underscores? Makes for ugly function
Terry Reedy wrote:
> You could discourage name use by not documenting the actual, internal name
> of the parameters.
The issue we had was that the name wasn't documented at all, the users
simply looked at the code and began using the keyword name. This may
well be an area where "we're all adul
In article
<[EMAIL PROTECTED]>,
"Guido van Rossum" <[EMAIL PROTECTED]> wrote:
> On 5/2/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> > Terry Reedy wrote:
> >
> > > my way to call your example (given the data in separate variables):
> > > make_person(name, age, phone, location)
> > > your way:
>
I've used a double leading underscore on the name. Works great for methods!
On 5/2/06, Terry Reedy <[EMAIL PROTECTED]> wrote:
>
> "Benji York" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> > I've not followed the PEP 3102 (keyword-only arguments) discussion
> > closely enough to
"Benji York" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> I've not followed the PEP 3102 (keyword-only arguments) discussion
> closely enough to know if this has been mentioned, but we were
> discussing a need at work today for the ability to enforce position-only
> arguments.
Y
On 5/2/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Brett Cannon wrote:
> > One is whether a signature object should be automatically created for
> > every function. As of right now the PEP I am drafting has it on a
> > per-need basis and have it assigned to __signature__ through a
> > built-in f
Guido van Rossum wrote:
> I see test failures in current HEAD on my Google Red Hat Linux desktop
> that the buildbots don't seem to have:
>
> ./python -E -tt ../Lib/test/regrtest.py test_ctypes
> test_ctypes
> test test_ctypes failed -- errors occurred; run in verbose mode for details
>
> More de
> > How about this?
> >
> > if any(x==5 for x in seq):
>
> Aren't all of these equivalent to:
>
> if 5 in seq:
> ...
Of course. However, the original example was pretty clearly intended to be
an illustrative instance of a more general problem. Rewriting the example
as any(x==5 for x
Guido van Rossum wrote:
> I see test failures in current HEAD on my Google Red Hat Linux desktop
> that the buildbots don't seem to have:
>
> ./python -E -tt ../Lib/test/regrtest.py test_ctypes
> test_ctypes
> test test_ctypes failed -- errors occurred; run in verbose mode for details
>
> More de
I've not followed the PEP 3102 (keyword-only arguments) discussion
closely enough to know if this has been mentioned, but we were
discussing a need at work today for the ability to enforce position-only
arguments.
The specific instance was an argument that was intended to be used as a
positional a
I see test failures in current HEAD on my Google Red Hat Linux desktop
that the buildbots don't seem to have:
./python -E -tt ../Lib/test/regrtest.py test_ctypes
test_ctypes
test test_ctypes failed -- errors occurred; run in verbose mode for details
More details from running this manually:
$ ./py
Georg Brandl wrote:
>Guido van Rossum wrote:
>
>
>>Backticks certainly are deprecated -- Py3k won't have them (nor will
>>they become available for other syntax; they are undesirable
>>characters due to font issues and the tendency of word processing
>>tools to generate backticks in certain case
Guido van Rossum wrote:
> Backticks certainly are deprecated -- Py3k won't have them (nor will
> they become available for other syntax; they are undesirable
> characters due to font issues and the tendency of word processing
> tools to generate backticks in certain cases where you type forward
> t
On 5/2/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Terry Reedy wrote:
>
> > my way to call your example (given the data in separate variables):
> > make_person(name, age, phone, location)
> > your way:
> > make_person(name=name, age=age, phone=phone, location = location)
>
> For situations like
On 5/2/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Maybe we should just expose a basic interface to replace the four lines of
> boilerplate (the docstring makes this look more complicated than it really
> is!):
+1
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
On 5/2/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> > Nick, do you have it in you to fix PEP 343? Or at least come up with a
> > draft patch? We can take this off-linel with all the +0's and +1's
> > coming in I'm pretty comfortable with this change now, although we
> > should probably wait until
On Tue, May 02, 2006, Tim Peters wrote:
>
>> Author: neal.norwitz
>> Date: Tue May 2 06:43:14 2006
>> New Revision: 45850
>>
>> Modified:
>>python/trunk/Lib/test/test_subprocess.py
>>python/trunk/Objects/fileobject.c
>>python/trunk/Python/bltinmodule.c
>> Log:
>> SF #1479181: split ope
I'm working on setting up a sprint in the Washington DC area;
currently I have a lead that would be in Arlington. I'd like to
discuss the date on python-dev in order to coordinate with other
events.
The sprint has no particular goal, so people might just hack on their
core-related projects. It c
On Tue, May 02, 2006, Nick Coghlan wrote:
> Greg Ewing wrote:
>> Josiah Carlson wrote:
>>>
>>> and am +0 on the double use below:
>>>
>>> for x in y:
>>> for x in z:
>>
>> Can anyone think of a plausible use case for that?
>
> This really seems more like the domain of pychecker/pylint
Phillip J. Eby wrote:
> And for the case where the compiler can tell the variable is accessed
> before it's defined, there's definitely something wrong. This code, for
> example, is definitely missing a "global" and the compiler could in
> principle tell:
>
> foo = 1
>
> def bar():
Greg Ewing wrote:
> Josiah Carlson wrote:
>> and am +0 on the double use below:
>>
>> for x in y:
>> for x in z:
>
> Can anyone think of a plausible use case for that?
This really seems more like the domain of pychecker/pylint rather than the
compiler. The code may be a bad idea, but
Josiah Carlson wrote:
> for line in lines:
> line = line.rstrip()
> ...
>
> I'm generally -0 on the "raise a SyntaxError" in this particular case,
That's a good point. I'm inclined to agree.
I think I might have even done something like
that recently, but I can't remember the
Terry Reedy wrote:
> my way to call your example (given the data in separate variables):
> make_person(name, age, phone, location)
> your way:
> make_person(name=name, age=age, phone=phone, location = location)
For situations like that, I've sometimes thought
it would be useful to be able to
Brett Cannon wrote:
> One is whether a signature object should be automatically created for
> every function. As of right now the PEP I am drafting has it on a
> per-need basis and have it assigned to __signature__ through a
> built-in function or putting it 'inspect'. Now automatically creating
Guido van Rossum wrote:
> On 4/30/06, Georg Brandl <[EMAIL PROTECTED]> wrote:
>> Guido van Rossum wrote:
>>> I expect that at some point people will want to tweak what gets copied
>>> by _update_wrapper() -- e.g. some attributes may need to be
>>> deep-copied, or personalized, or skipped, etc.
>> W
Guido van Rossum wrote:
> On 5/1/06, James Y Knight <[EMAIL PROTECTED]> wrote:
>> Don't forget that the majority of users will never have heard any of
>> these discussions nor have used 2.5a1 or 2.5a2. Choose the best term
>> for them, not for the readers of python-dev.
>
> I couldn't agree more!
Tim Peters wrote:
SF #1479181: split open() and file() from being aliases for each other.
>
>>> Umm ... why?
>
> [/F]
>> so that introspection tools can support GvR's pronouncement that "open"
>> should be used to open files, and "file" should be used as a type
>> representing
>> standard (c
"""
Python Language and Libraries
A track about Python the Language, all batteries included. Talks about
the language, language evolution, patterns and idioms, implementations
(CPython, IronPython, Jython, PyPy ...) and implementation issues belong
to the track. So do talks about the standard l
Greg Ewing <[EMAIL PROTECTED]> wrote:
>
> Delaney, Timothy (Tim) wrote:
>
> > So would this also be a SyntaxError?
> >
> > for x in stuff:
> > x = somethingelse
>
> That would be something to be debated. I don't
> really mind much one way or the other.
for line in lines:
>>> SF #1479181: split open() and file() from being aliases for each other.
>> Umm ... why?
[/F]
> so that introspection tools can support GvR's pronouncement that "open"
> should be used to open files, and "file" should be used as a type representing
> standard (current stdio-based) file handles
38 matches
Mail list logo
