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.
--
Greg
___
Python-Dev mailing list
On 5/1/06, Tim Peters [EMAIL PROTECTED] wrote:
Author: neal.norwitz
Date: Tue May 2 06:43:14 2006
New Revision: 45850
Modified:
python/trunk/Doc/lib/libfuncs.tex
python/trunk/Lib/test/test_subprocess.py
python/trunk/Misc/NEWS
python/trunk/Objects/fileobject.c
[Tim]
...
test_subprocess failing on all the Windows buildbots
[Neal]
I tried to fix that breakage.
You succeeded! Thanks.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
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.
Maybe
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:
line =
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
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 (current stdio-based)
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! (Another
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.
What exactly do
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
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 say
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
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 I don't
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():
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 rather than
the
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
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 open() and file() from
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 later
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 that, I've
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
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 cases where
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:
$
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
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 details
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 details
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 function or
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.
You
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:
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 adults
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
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.
--
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
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 yesterday
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,
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 the same thing as
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. fdrake at acm.org
___
Python-Dev mailing list
36 matches
Mail list logo
