Re: [Python-Dev] Continuing 2.x
On Sun, Oct 31, 2010 at 10:41 AM, Terry Reedy wrote: > The few issues that would get such a 2.7+ tag can just as well be marked > 2.7/closed/postponed. Using closed+postponed as the resolution for 2.x specific feature requests sounds fine. Feature requests that are also applicable to 3.x can just be bumped to refer to the in-development 3.x version (with beta 1 less than 2 weeks away, that will typically be 3.3 now). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r85902 - in python/branches/py3k/Lib: os.py test/test_os.py
On Fri, Oct 29, 2010 at 10:38 AM, victor.stinner
wrote:
> try:
> - path_list = env.get('PATH')
> + # ignore BytesWarning warning
> + with warnings.catch_warnings(record=True):
> + path_list = env.get('PATH')
This looks odd to me. You're requesting that the warnings be saved,
but not actually retrieving the list object where they're recorded
from the __enter__ method.
The correct way to suppress a specific warning type is:
with warnings.catch_warnings():
warnings.simplefilter("ignore", BytesWarning)
path_list = env.get('PATH')
I'll also echo Benjamin's concern with the embedded import. Of such
things, deadlocks are created. If there's a dependency problem between
os and the warnings build process in a fresh build, then it is better
to simply fix that rather than risking the deadlock.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r86000 - python/branches/py3k/Lib/test/test_fileio.py
On Sun, Oct 31, 2010 at 9:56 AM, brian.curtin
wrote:
> Author: brian.curtin
> Date: Sun Oct 31 01:56:45 2010
> New Revision: 86000
>
> Log:
> Fix ResourceWarning about unclosed file
>
>
> Modified:
> python/branches/py3k/Lib/test/test_fileio.py
>
> Modified: python/branches/py3k/Lib/test/test_fileio.py
> ==
> --- python/branches/py3k/Lib/test/test_fileio.py (original)
> +++ python/branches/py3k/Lib/test/test_fileio.py Sun Oct 31 01:56:45
> 2010
> @@ -260,7 +260,6 @@
> # OS'es that don't support /dev/tty.
> pass
> else:
> - f = _FileIO("/dev/tty", "a")
> self.assertEquals(f.readable(), False)
> self.assertEquals(f.writable(), True)
> if sys.platform != "darwin" and \
Doesn't that delete the file object that the next two lines are trying to test?
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r85902 - in python/branches/py3k/Lib: os.py test/test_os.py
On Mon, Nov 1, 2010 at 12:01 AM, Nick Coghlan wrote:
> On Fri, Oct 29, 2010 at 10:38 AM, victor.stinner
> wrote:
>> try:
>> - path_list = env.get('PATH')
>> + # ignore BytesWarning warning
>> + with warnings.catch_warnings(record=True):
>> + path_list = env.get('PATH')
>
> This looks odd to me. You're requesting that the warnings be saved,
> but not actually retrieving the list object where they're recorded
> from the __enter__ method.
>
> The correct way to suppress a specific warning type is:
>
> with warnings.catch_warnings():
> warnings.simplefilter("ignore", BytesWarning)
> path_list = env.get('PATH')
Alternatively, specifically in the test suite, you can use:
with test.support.check_warnings(('', BytesWarning), quiet=True):
path_list = env.get('PATH')
(Without the "quiet=True" the test would fail in release mode, when
the warning *isn't* issued)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Change to logging Formatters: support for alternative format styles
Eric Smith trueblade.com> writes:
> I keep meaning to review this but haven't had time. One thing I want to
> look at specifically is the ability to put the time formatting into the
> str.format version of the format string. Now that the time format
> specifier can be included in the format string, it's no longer necessary
> to have the asctime inspection hack that's currently used in order to
> avoid formatting the time. It would be good if we could remove the
> formatTime logic for str.format, although I'm not sure how practical it
> is. I suspect it's too baked-in to the design, but I'm hopeful.
Well, asctime checks would be in there for the other format styles anyway, and
you don't gain anything by making str.format a special case where the check is
avoided. The %-style will be around for a while, particularly as AFAICT
{}-formatting is still nominally slower than %-formatting [it *is* a lot more
flexible, so I can understand that]and people still cling to the "logging is
slow" meme, despite there being no hard numbers presented in evidence.
You don't have to specify asctime in the format string, but remember that since
Python logging predates datetime [both came in at Python 2.3 but the logging
package was independently available before, and compatible with Python 1.5.2 for
a while after introduction], times in logging are floats as per time.time().
IIUC you need a datetime.datetime object to do the formatting automatically
using str.format, so if one could e.g. use a Filter or LoggerAdapter to get a
datetime value into the LogRecord, then you could use {}-formatting without
{asctime} but with some other LogRecord attribute. I think the way it is now for
3.2 is the path of least resistance, though.
BTW as it is now, the asctime "hack" is less of a hack than it used to be; it
was an inline check before, but now can be easily reimplemented e.g. via
subclassing and overriding the usesTime() method.
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r86000 - python/branches/py3k/Lib/test/test_fileio.py
On Sun, Oct 31, 2010 at 09:20, Nick Coghlan wrote:
> On Sun, Oct 31, 2010 at 9:56 AM, brian.curtin
> wrote:
> > Author: brian.curtin
> > Date: Sun Oct 31 01:56:45 2010
> > New Revision: 86000
> >
> > Log:
> > Fix ResourceWarning about unclosed file
> >
> >
> > Modified:
> > python/branches/py3k/Lib/test/test_fileio.py
> >
> > Modified: python/branches/py3k/Lib/test/test_fileio.py
> >
> ==
> > --- python/branches/py3k/Lib/test/test_fileio.py(original)
> > +++ python/branches/py3k/Lib/test/test_fileio.pySun Oct 31
> 01:56:45 2010
> > @@ -260,7 +260,6 @@
> > # OS'es that don't support /dev/tty.
> > pass
> > else:
> > -f = _FileIO("/dev/tty", "a")
> > self.assertEquals(f.readable(), False)
> > self.assertEquals(f.writable(), True)
> > if sys.platform != "darwin" and \
>
> Doesn't that delete the file object that the next two lines are trying to
> test?
>
> Cheers,
> Nick.
It gets created in the try block above, so the file was being created twice
but deleted once.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Change to logging Formatters: support for alternative format styles
Olemis Lang gmail.com> writes:
>
> On Fri, Oct 29, 2010 at 10:07 AM, Barry Warsaw python.org> wrote:
> > I haven't played with it yet, but do you think it makes sense to add a
> > 'style' keyword argument to basicConfig()? That would make it pretty easy
> > to get the formatting style you want without having to explicitly
> > instantiate a Formatter, at least for simple logging clients.
> >
>
> Since this may be considered as a little sophisticated, I'd rather
> prefer these new classes to be added to configuration sections using
> fileConfig (and default behavior if missing), and still leave
> `basicConfig` unchanged (i.e. *basic*) .
>
Actually it's no biggie to have an optional style argument for basicConfig.
People who don't use it don't have to specify it; the style argument would only
apply if format was specified.
For some people, use of {} over % is more about personal taste than about the
actual usage of str.format's flexibility; we may as well accommodate that
preference, as it encourages in a small way the use of {}-formatting.
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r86000 - python/branches/py3k/Lib/test/test_fileio.py
On Mon, Nov 1, 2010 at 12:55 AM, Brian Curtin wrote: > > It gets created in the try block above, so the file was being created twice > but deleted once. Ah, right. My brain read that "else:" as an except clause for some reason (possibly a sign that I should have gone to bed a while ago...). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Change to logging Formatters: support for alternative format styles
On Sun, 31 Oct 2010 14:55:34 -, Vinay Sajip wrote:
> Olemis Lang gmail.com> writes:
> > On Fri, Oct 29, 2010 at 10:07 AM, Barry Warsaw python.org>
> > wrote:
> > > I haven't played with it yet, but do you think it makes sense to add a
> > > 'style' keyword argument to basicConfig()? Â That would make it pretty
> > > easy
> > > to get the formatting style you want without having to explicitly
> > > instantiate a Formatter, at least for simple logging clients.
> > >
> >
> > Since this may be considered as a little sophisticated, I'd rather
> > prefer these new classes to be added to configuration sections using
> > fileConfig (and default behavior if missing), and still leave
> > `basicConfig` unchanged (i.e. *basic*) .
> >
>
> Actually it's no biggie to have an optional style argument for basicConfig.
> People who don't use it don't have to specify it; the style argument would
> only
> apply if format was specified.
>
> For some people, use of {} over % is more about personal taste than about the
> actual usage of str.format's flexibility; we may as well accommodate that
> preference, as it encourages in a small way the use of {}-formatting.
+1
--
R. David Murray www.bitdance.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Cleaning-up the new unittest API
On Oct 29, 2010, at 08:14 PM, Raymond Hettinger wrote: >I would like to simplify and clean-up the API for the unittest module >by de-documenting assertSetEqual(), assertDictEqual(), >assertListEqual, and assertTupleEqual(). As a general principle, I think all public API methods should be documented. That still leaves plenty of room for simplification. Some ways to address both concerns could be: - moving the documentation to an "advanced" or "complete reference" section - make the methods non-public by prepending an underscore - leaving them public but adding deprecation warnings to the code >All of those methods are already called automatically by >assertEqual(), so those methods never need to be called directly. >Or, if you need to be more explicit about the type checking for >sequences, the assertSequenceEqual() method will suffice. >Either way, there's no need to expose the four type specific methods. It sounds like those methods should not be public then. >Given the purpose of the unittest module, it's important that >the reader have a crystal clear understanding of what a test >is doing. Their attention needs to be focused on the subject >of the test, not on questioning the semantics of the test method. That's different documentation than a complete reference manual. A reference manual should contain all public methods, functions, classes and attributes. It's there so that when you see some third party code that uses it, you have an authoritative description of the semantics of that method. We owe it to our users to have complete reference material. OTOH, we also owe them clear guidelines on best practices for the use of our API. Often, this is either obvious or can live in the same documentation. By sectioning the documentation, the module docs can be organized to give both a user guide with opinionated recommendations, and a complete reference manual. Cheers, -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Continuing 2.x
On Oct 29, 2010, at 04:23 PM, Benjamin Peterson wrote: >At the moment, I'm planning to do regular maintenance releases for 3.1 and >2.7 roughly every 6 months. Cool. The actual interval doesn't matter as much as the regularity. I say that speaking as a semi-former RM who sadly didn't adhere to much regularity. ;/ Cheers, -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Cleaning-up the new unittest API
On Sun, Oct 31, 2010 at 9:11 AM, Barry Warsaw wrote: > On Oct 29, 2010, at 08:14 PM, Raymond Hettinger wrote: > > >I would like to simplify and clean-up the API for the unittest module > >by de-documenting assertSetEqual(), assertDictEqual(), > >assertListEqual, and assertTupleEqual(). > > As a general principle, I think all public API methods should be > documented. > > That still leaves plenty of room for simplification. Some ways to address > both concerns could be: > > - moving the documentation to an "advanced" or "complete reference" section > Agreed, I perfer simply deemphasizing these methods by reorganizing the documentation and mentioning in their documentation to, "just use assertEqual." De-documenting them is the first step towards causing unnecessary pain by taking either of the next two steps: - make the methods non-public by prepending an underscore > - leaving them public but adding deprecation warnings to the code > Please do not make any existing released methods from the unittest module non-public or add any deprecation warnings. That will simply cause unnecessary code churn and pain for people porting their code from one version to the next without benefiting anyone. > >All of those methods are already called automatically by > >assertEqual(), so those methods never need to be called directly. > For new code I agree and we should document them as such. They _do_ have value on their own when called directly. They offer an explicit type check as part of their assertion and are much easier to read for that than manually passing the parameter to assertSequenceEqual(a, b, seq_type=xxx). How often they are used for that reason is hard for me to measure as the giant code base we have at work that uses these was written over the years prior to assertEqual automagically calling these methods based on input types so its uses tend to be a mix of cases where the type check doesn't matter and a small fraction of cases where it is important. The smarts about automagically calling an appropriate method from assertEqual were added during the sprints while contributing them at PyCon 2009. > >Or, if you need to be more explicit about the type checking for > >sequences, the assertSequenceEqual() method will suffice. > >Either way, there's no need to expose the four type specific methods. > > It sounds like those methods should not be public then. > I strongly prefer de-documenting them to making anything already released as public be nonpublic. That leads to pain for people moving to new versions of Python. There is no maintenance burden to keeping these trivial methods for the convenience of code that has already used them. > >Given the purpose of the unittest module, it's important that > >the reader have a crystal clear understanding of what a test > >is doing. Their attention needs to be focused on the subject > >of the test, not on questioning the semantics of the test method. > > That's different documentation than a complete reference manual. A > reference > manual should contain all public methods, functions, classes and > attributes. > It's there so that when you see some third party code that uses it, you > have > an authoritative description of the semantics of that method. We owe it to > our users to have complete reference material. > > OTOH, we also owe them clear guidelines on best practices for the use of > our > API. Often, this is either obvious or can live in the same documentation. > By > sectioning the documentation, the module docs can be organized to give both > a > user guide with opinionated recommendations, and a complete reference > manual. > Agreed. -gps ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] r86046 - python/branches/py3k/Lib/test/test_smtplib.py
On Sun, 31 Oct 2010 18:15:43 +0100 (CET)
benjamin.peterson wrote:
>
> # SimSMTPChannel doesn't fully support LOGIN or CRAM-MD5 auth because
> they
> # require a synchronous read to obtain the credentials...so instead smtpd
> @@ -503,6 +504,7 @@
> except smtplib.SMTPAuthenticationError as err:
> if sim_auth_login_password not in str(err):
> raise "expected encoded password not found in error message"
> +smtp.close()
Perhaps the string-raising above should be converted to 3.x-compliant
code?
> def testAUTH_CRAM_MD5(self):
> self.serv.add_feature("AUTH CRAM-MD5")
> @@ -512,6 +514,7 @@
> except smtplib.SMTPAuthenticationError as err:
> if sim_auth_credentials['cram-md5'] not in str(err):
> raise "expected encoded credentials not found in error
> message"
> +smtp.close()
Same here.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] test_grp regression test fails with NIS entries present
The regression tests for py3k (or, I think, any branch) fail on one of my machines because test_grp chokes if /etc/group contains a "+" line, which is a directive to pull information from NIS. The test enumerates all entries in /etc/group using grp.getgrall() and verifies that it can look up each entry by name using grp.getgrnam(). The current behavior of grp.getgrall() is to return entries whose names start with plus or minus signs (NIS-related lines) as if they were regular entries. The result is that the test tries to look up the name "+" and fails because no entry is found. It turns out that a bug on this issue has existed since 2003: http://bugs.python.org/issue775964 The bug originally indicated that the problem is specific to Red Hat, but that is not the case because I ran into it on Debian Squeeze. According to a comment on the bug, this syntax in the group file has been deprecated for a long time, which is why the issue rarely comes up. I believe the right thing to do at this point is to keep the behavior of grp.getgrall(), but document that it will return NIS-related lines along with regular entries and to modify the test to not try to look up those entries with grp.getgrnam(). I've attached a patch to the bug that makes these changes and results in the test passing. Is it possible that someone can review/ checkin the patch? Thanks. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] str.format_from_mapping
What are your thoughts on adding a str.format_from_mapping (or similar
name, maybe the suggested "format_map") to 3.2? See
http://bugs.python.org/issue6081 . This method would be similar to
"%(foo)s %(bar)s" % d, where d is a dict (or rather any mapping object),
but of course would use str.format syntax: "{foo}
{bar}".format_from_mapping(d).
I like the idea. It's particularly handy when converting from %-formatting.
Eric.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] str.format_from_mapping
On Sun, 31 Oct 2010 16:39:44 -0400
Eric Smith wrote:
> What are your thoughts on adding a str.format_from_mapping (or similar
> name, maybe the suggested "format_map") to 3.2? See
> http://bugs.python.org/issue6081 . This method would be similar to
> "%(foo)s %(bar)s" % d, where d is a dict (or rather any mapping object),
> but of course would use str.format syntax: "{foo}
> {bar}".format_from_mapping(d).
I must be missing something, but what's the difference with
XXX.format(**d)?
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] str.format_from_mapping
2010/10/31 Antoine Pitrou :
> On Sun, 31 Oct 2010 16:39:44 -0400
> Eric Smith wrote:
>
>> What are your thoughts on adding a str.format_from_mapping (or similar
>> name, maybe the suggested "format_map") to 3.2? See
>> http://bugs.python.org/issue6081 . This method would be similar to
>> "%(foo)s %(bar)s" % d, where d is a dict (or rather any mapping object),
>> but of course would use str.format syntax: "{foo}
>> {bar}".format_from_mapping(d).
>
> I must be missing something, but what's the difference with
> XXX.format(**d)?
It allows arbitrary mappings.
--
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] str.format_from_mapping
On Sun, 31 Oct 2010 16:02:08 -0500
Benjamin Peterson wrote:
> 2010/10/31 Antoine Pitrou :
> > On Sun, 31 Oct 2010 16:39:44 -0400
> > Eric Smith wrote:
> >
> >> What are your thoughts on adding a str.format_from_mapping (or similar
> >> name, maybe the suggested "format_map") to 3.2? See
> >> http://bugs.python.org/issue6081 . This method would be similar to
> >> "%(foo)s %(bar)s" % d, where d is a dict (or rather any mapping object),
> >> but of course would use str.format syntax: "{foo}
> >> {bar}".format_from_mapping(d).
> >
> > I must be missing something, but what's the difference with
> > XXX.format(**d)?
>
> It allows arbitrary mappings.
Ah, yes, sorry. I should have read the issue before posting. It's a bit
embarassing to add a method for that, though, while formatting regular
dicts doesn't need it.
Regards
Antoine.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] r86046 - python/branches/py3k/Lib/test/test_smtplib.py
On 10/31/2010 1:44 PM, Antoine Pitrou wrote:
On Sun, 31 Oct 2010 18:15:43 +0100 (CET)
benjamin.peterson wrote:
# SimSMTPChannel doesn't fully support LOGIN or CRAM-MD5 auth because they
# require a synchronous read to obtain the credentials...so instead smtpd
@@ -503,6 +504,7 @@
except smtplib.SMTPAuthenticationError as err:
if sim_auth_login_password not in str(err):
raise "expected encoded password not found in error message"
+smtp.close()
Perhaps the string-raising above should be converted to 3.x-compliant
code?
Since raise 'string' itself raises a TypeError in 3.x, it must be that
the raise statement has never been executed in 3.x testing or that the
TypeError has not been noticed to be an erroneous error.
def testAUTH_CRAM_MD5(self):
self.serv.add_feature("AUTH CRAM-MD5")
@@ -512,6 +514,7 @@
except smtplib.SMTPAuthenticationError as err:
if sim_auth_credentials['cram-md5'] not in str(err):
raise "expected encoded credentials not found in error
message"
+smtp.close()
Same here.
--
Terry Jan Reedy
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r86066 - python/branches/py3k/Doc/library/functions.rst
On Sun, Oct 31, 2010 at 5:23 PM, raymond.hettinger wrote: .. > + For some use cases, there a good alternatives to :func:`sum`. This sentence is missing a verb. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] str.format_from_mapping
On 10/31/2010 2:02 PM, Benjamin Peterson wrote:
2010/10/31 Antoine Pitrou:
> On Sun, 31 Oct 2010 16:39:44 -0400
> Eric Smith wrote:
>
>> What are your thoughts on adding a str.format_from_mapping (or similar
>> name, maybe the suggested "format_map") to 3.2? See
>> http://bugs.python.org/issue6081 . This method would be similar to
>> "%(foo)s %(bar)s" % d, where d is a dict (or rather any mapping object),
>> but of course would use str.format syntax: "{foo}
>> {bar}".format_from_mapping(d).
>
> I must be missing something, but what's the difference with
> XXX.format(**d)?
It allows arbitrary mappings.
Other than the language moratorium, why are arbitrary mappings not
allowed for the (**d) syntax?
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] str.format_from_mapping
2010/10/31 Glenn Linderman :
> On 10/31/2010 2:02 PM, Benjamin Peterson wrote:
>
> 2010/10/31 Antoine Pitrou :
>
>> On Sun, 31 Oct 2010 16:39:44 -0400
>> Eric Smith wrote:
>>
>
>>> What are your thoughts on adding a str.format_from_mapping (or similar
>>> name, maybe the suggested "format_map") to 3.2? See
>>> http://bugs.python.org/issue6081 . This method would be similar to
>>> "%(foo)s %(bar)s" % d, where d is a dict (or rather any mapping object),
>>> but of course would use str.format syntax: "{foo}
>>> {bar}".format_from_mapping(d).
>
>>
>> I must be missing something, but what's the difference with
>> XXX.format(**d)?
>
> It allows arbitrary mappings.
>
> Other than the language moratorium, why are arbitrary mappings not allowed
> for the (**d) syntax?
They are; they're just copied into a dictionary.
--
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] str.format_from_mapping
On 10/31/2010 6:28 PM, Glenn Linderman wrote:
On 10/31/2010 2:02 PM, Benjamin Peterson wrote:
2010/10/31 Antoine Pitrou:
> On Sun, 31 Oct 2010 16:39:44 -0400
> Eric Smith wrote:
>
>> What are your thoughts on adding a str.format_from_mapping (or similar
>> name, maybe the suggested "format_map") to 3.2? See
>> http://bugs.python.org/issue6081 . This method would be similar to
>> "%(foo)s %(bar)s" % d, where d is a dict (or rather any mapping object),
>> but of course would use str.format syntax: "{foo}
>> {bar}".format_from_mapping(d).
>
> I must be missing something, but what's the difference with
> XXX.format(**d)?
It allows arbitrary mappings.
Other than the language moratorium, why are arbitrary mappings not
allowed for the (**d) syntax?
An arbitrary mapping would be converted to a dict. That disallows using
a subclass with __missing__ defined, among other things. See the
discussion in the issue.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Cleaning-up the new unittest API
Raymond Hettinger wrote: > I looked at this again and think we should just remove > assertItemsEqual() from Py3.2 and dedocument it in Py2.7. It is listed > as being new in 3.2 so nothing is lost. One thing that would be lost is that correct Python 2.7 code using assertItemsEqual would no longer run on 3.2. > The sole benefit over the more explicit variants like > assertEqual(set(a), set(b)) and assertEqual(sorted(a), sorted(b)) is > that it handles a somewhat rare corner case where neither of those > work (unordered comparison of non-compable types when you do care > about duplicates). Another benefit is that it gives better descriptions of differences. See http://bugs.python.org/issue9977 for an example. -M- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] str.format_from_mapping
On 10/31/2010 3:32 PM, Eric Smith wrote:
On 10/31/2010 6:28 PM, Glenn Linderman wrote:
On 10/31/2010 2:02 PM, Benjamin Peterson wrote:
2010/10/31 Antoine Pitrou:
> On Sun, 31 Oct 2010 16:39:44 -0400
> Eric Smith wrote:
>
>> What are your thoughts on adding a str.format_from_mapping (or
similar
>> name, maybe the suggested "format_map") to 3.2? See
>> http://bugs.python.org/issue6081 . This method would be
similar to
>> "%(foo)s %(bar)s" % d, where d is a dict (or rather any
mapping object),
>> but of course would use str.format syntax: "{foo}
>> {bar}".format_from_mapping(d).
>
> I must be missing something, but what's the difference with
> XXX.format(**d)?
It allows arbitrary mappings.
Other than the language moratorium, why are arbitrary mappings not
allowed for the (**d) syntax?
An arbitrary mapping would be converted to a dict.
Yes, but why convert? I suppose it has something to do with the case
where there are named parameters, in addition to a **kwargs formal, and
the mixing and matching that happens as a result.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r85934 - in python/branches/py3k: Misc/NEWS Modules/socketmodule.c
On 10/30/2010 4:08 PM, Martin v. Löwis wrote: >> I think size should be in TCHARs, not in bytes. (MSDN says so) >> And GetComputerName's signature differs from MSDN. (Maybe should >> use GetComputerNameExW again?) > > You are right. So how about this patch? Still not quite right. The call to GetComputerNameExW after ERROR_MORE_DATA (which gives the number of *bytes* needed) still needs to pass "size/sizeof(wchar_t)" back into GetComputerNameExW since it wants the number TCHARs. I don't think the +1 is needed either (MSDN says it already included the null-terminator in the byte count. -- Scott Dial sc...@scottdial.com scod...@cs.indiana.edu ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] str.format_from_mapping
2010/10/31 Glenn Linderman :
> On 10/31/2010 3:32 PM, Eric Smith wrote:
>
> On 10/31/2010 6:28 PM, Glenn Linderman wrote:
>
> On 10/31/2010 2:02 PM, Benjamin Peterson wrote:
>
> 2010/10/31 Antoine Pitrou:
>
>> On Sun, 31 Oct 2010 16:39:44 -0400
>> Eric Smith wrote:
>>
>
>>> What are your thoughts on adding a str.format_from_mapping (or similar
>>> name, maybe the suggested "format_map") to 3.2? See
>>> http://bugs.python.org/issue6081 . This method would be similar to
>>> "%(foo)s %(bar)s" % d, where d is a dict (or rather any mapping object),
>>> but of course would use str.format syntax: "{foo}
>>> {bar}".format_from_mapping(d).
>
>>
>> I must be missing something, but what's the difference with
>> XXX.format(**d)?
>
> It allows arbitrary mappings.
>
> Other than the language moratorium, why are arbitrary mappings not
> allowed for the (**d) syntax?
>
> An arbitrary mapping would be converted to a dict.
>
> Yes, but why convert?
Because callees always get a dictionary *copy* of the arguments.
--
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Cleaning-up the new unittest API
On Oct 31, 2010, at 09:54 AM, Gregory P. Smith wrote: >> - moving the documentation to an "advanced" or "complete reference" section >> > >Agreed, I perfer simply deemphasizing these methods by reorganizing the >documentation and mentioning in their documentation to, "just use >assertEqual." De-documenting them is the first step towards causing >unnecessary pain by taking either of the next two steps: > >- make the methods non-public by prepending an underscore >> - leaving them public but adding deprecation warnings to the code >> > >Please do not make any existing released methods from the unittest module >non-public or add any deprecation warnings. That will simply cause >unnecessary code churn and pain for people porting their code from one >version to the next without benefiting anyone. I was hoping someone would get my not-too-subtle hint. :) -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] str.format_from_mapping
On Oct 31, 2010, at 04:39 PM, Eric Smith wrote: >What are your thoughts on adding a str.format_from_mapping (or similar >name, maybe the suggested "format_map") to 3.2? +1 for the shorter name. -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] new buffer in python2.7
You just moved your copying down one level into stream.read(). This magic function must be implemented by possibly concatenating several "socket.recv()" calls. This invariably involves data copying, either by "".join() or stringio.write() K -Original Message- From: python-dev-bounces+kristjan=ccpgames@python.org [mailto:python-dev-bounces+kristjan=ccpgames@python.org] On Behalf Of "Martin v. Löwis" Sent: Friday, October 29, 2010 18:15 To: python-dev@python.org Subject: Re: [Python-Dev] new buffer in python2.7 That is easy to achieve using the existing API: def read_and_unpack(stream, format): data = stream.read(struct.calcsize(format)) return struct.unpack(format, data) > Otherwise, I'm +1 on your suggestion, avoiding copying is a good thing. I believe my function also doesn't involve any unnecessary copies. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Cleaning-up the new unittest API
On 30/10/2010 06:56, Raymond Hettinger wrote:
On Oct 29, 2010, at 9:11 PM, Michael Foord wrote:
Just to clarify. The following fails in Python 3:
sorted([3, 1, 2, None])
If you want to compare that two iterables containing heterogeneous
types have the same members then it is tricky to implement correctly
and assertItemsEqual does it for you.
I agree that the name is not ideal and would be happy to change the
name (deprecating the old name as it was released in 2.7). API churn
is as bad as API bloat, but at least changing the name is something
only done once.
Sorry for the noise. Suggested alternative name:
assertElementsEqual
The docs need updating to make it clear that the method isn't just a
synonym for assertEqual(sorted(iter1), sorted(iter2)) and that it
works with unorderable types.
I looked at this again and think we should just remove
assertItemsEqual() from Py3.2 and dedocument it in Py2.7. It is listed
as being new in 3.2 so nothing is lost.
As it has been released in 2.7 (and in unittest2 for earlier versions of
Python) removing it would add another pain point for those porting from
Python 2 to 3. From a backwards compatibility point of view this method
has been released (it is only new in 3.2 for the Python 3 series).
Note that for this issues plus the other cleanup related topics we have
been discussing Raymond has created issue 10273:
http://bugs.python.org/issue10273
A new name like assertElementsEqual is an improvement because it
doesn't suggest something like assertEqual(d.items(), d.items()), but
it falls short in describing its key features:
* the method doesn't care about order
Something that implied order would be good but we shouldn't let the
perfect be the enemy of the good.
* it does care about duplicates
Both the old name and the new one imply that it does care about
duplicates (to me at least).
* it don't need hashability
* it can handle sequences of non-comparable types
The name doesn't imply that it needs hashability or comparable types
either (although the latter needs to be documented as the current
documentation could be read as saying that comparable types are needed).
The name doesn't need to include all its *non-requirements*, it just
needs to describe what it does.
Also, I think the O(n**2) behavior is unexpected.
I agree that this should be fixed.
There is a O(n log n) fast-path but it has a bug and needs to be
removed. See issue 10242.
Having a more efficient 'slow-path' and moving to that by default would
fix it. The bug is only a duplicate of the bug in sorted - caused by the
fact that sets / frozensets can't be sorted in the standard Python way
(their less than comparison adheres to the set definition). This is
something that will probably surprise many Python developers:
>>> a = [{2,4}, {1,2}]
>>> b = a[::-1]
>>> sorted(a)
[set([2, 4]), set([1, 2])]
>>> sorted(b)
[set([1, 2]), set([2, 4])]
(Fixing the bug in sorted would fix assertItemsEqual ;-)
As I stated in my previous email, the functionality is still useful. Add
on the fact that this has already been released I'm -1 one removing, +1
on fixing O(n**2) behaviour and +0 on an alternative name.
The sole benefit over the more explicit variants like
assertEqual(set(a), set(b)) and assertEqual(sorted(a), sorted(b)) is
that it handles a somewhat rare corner case where neither of those
work (unordered comparison of non-compable types when you do care
about duplicates). That particular case doesn't come-up much and isn't
suggested by either the current name or its proposed replacement.
I have test suites littered with self.assertEqual(sorted(expected),
sorted(actual)) - anywhere I care about the contents of a sequence but
not about the order it is generated in (perhaps created by iteration
over a set or dictionary). It is not uncommon for these lists to contain
None which makes them un-sortable in Python 3. Decorating the members
with something that allows a stable sort would fix that - and that is
one possible fix for the efficiency issue. It would probably propagate
the issue that sets / frozensets don't work with sorted.
FWIW, I checked-out some other unittest suites in other languages and
did not find an equivalent. That strongly suggests this is YAGNI and
it shouldn't be added in Py3.2. There needs to be more evidence of
need before putting this in. And if it goes in, it needs a really good
name that tells what operations are hidden behind the abstraction.
When reading test assertion, it is vital that the reader understand
exactly what is being tested. It's an API fail if a reader guesses
that assertElementsEqual(a,b) means list(a)==list(b); the test will
pass unintentionally.
I agree very much that asserts need to be readable. I think
assertSameElements is "good enough" on this score though.
All the best,
Michael
See:
http://www.phpunit.de/manual/3.4/en/api.html
http://kentbeck.github.com/junit/javadoc/latest
Re: [Python-Dev] new buffer in python2.7
>> def read_and_unpack(stream, format): >> data = stream.read(struct.calcsize(format)) >> return struct.unpack(format, data) >> >>> Otherwise, I'm +1 on your suggestion, avoiding copying is a good >>> thing. >> >> I believe my function also doesn't involve any unnecessary copies. > You just moved your copying down one level into stream.read(). This > magic function must be implemented by possibly concatenating > several "socket.recv()" calls. > This invariably involves data copying, either by "".join() or > stringio.write() Assuming there are multiple recv calls. For a typical struct, all data will come out of the stream with a single recv. so no join will be necessary. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
